Multi Model Database Management System
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.

PersiaDB - Multi Model Database

If you check any databases you can feel that all of them just add a layer to exiting infrastructure and non of them can be good for all type of data model! So We decide to take logic part of database from Storage Engine and be in code-generator to add to app logic layer instead an additional app. In storage engines even newest one like LevelDB and RocksDB have some fundemental problem e.g. they build in top of exiting FileSystems as defualts!! Some NewSQLs like Cockroach, arangodb, elassandra have not same but good in some use cases. So PersiaDB is just database code-generator not standalone stateless or stateful application! this means it can scale with your app scalability architecture!

Use Cases

  • Multi Model Datastore
  • Data Mining
  • Machine Learning & AI (Artificial intelligence)


We need to store and retrieve data in multi model! We have all futures like ACID, transaction in library layer. We don't support & suggest to use normalize data because of performance lack in data indexing. We don't need row lock for transaction query because we don't use update data in SE layer.


There is no update data! Just have write, get and delete in storage engine layer. UUID belong to the object can be used as version control of that record, So each object in each version have unique UUID. With this rule in every layer we can cache an object by its UUID and it is guaranty that always be same data on each UUID!

Object data structure

  • MetaData
  • Data


Due transaction or multi add and update data has many different scenario in each situation in distributed computing, Developer can send multi request in one connection but failed process must handle in logic layer.

Distributed data Index Engine

We need to store and retrieve data in any query that we index data! We must use SSD and DRAM for index data to speed up data lookup.

Replication Strategy

We choose replication strategy to indicate in storage engine layer. Developer can set needed replication storage and get related token that indicate where and how data must store! Replication data can be any of this startegy to cover CAP theory:

  • no replication
  • replicate once on the same rack
  • replicate once on a different rack, but same data center
  • replicate once on a different data center
  • replicate twice on two different data center
  • replicate once on a different rack, and once on a different data center


  • Compress & uncompress data by MIME ???


PersiaDB has very simple usage instructions! Just look at data-{}.go methods with their request and respond structures.

Production Ready!?

This package is under development and not ready to use in real production. It can have breakable changes until version 1 release. But we are glad to hear your experience or idea about this package. We use MySQL as storage engine for start. when PersiaOS released we switch to it.