OrigoDB is an in-memory event-sourced database engine for NET/Mono environments. It allows users to design custom data models to fit their needs. It is designed to be easy for developers to use, and may have worse performance in order to meet this goal.

Concurrency Control

Multi-version Concurrency Control (MVCC)

# Transactions OrigoDB does not explicitly support transactions. Each read and write is treated as a separate transaction, and access to the database is controlled by a reader/writer lock. Writes are strictly sequential and take an exclusive lock on the database, and reads run concurrently using a shared lock. A custom command class can be used if several reads and writes need to be executed as a single transaction. # Immutability OrigoDB has the option to use only immutable data structures in memory. Using this model, a write takes the state of the database as input and outputs a new state, which becomes the current state. When a read begins, it takes the current state as input, and uses this state for the duration of the read. Therefore, each transaction maintains its own copy of the database. Using this model, a read can occur concurrently with any other transactions (reads and/or writes), and at most one write occurs at a time.

Data Model

Relational Key/Value Document / XML Graph

OrigoDB supports several built-in data models. The built-in models are relational, document/XML, key-value pair, graph, Redis clone, and JavaScript. In addition to these generic data models, users can specify a custom data model using any .NET language. A custom model is an instance of the `Model class`, and includes custom commands and queries. All data models are stored as strongly typed graphs.

Foreign Keys


Query Interface

Custom API

All queries are written in C#. Queries can be based on LINQ, but must be in C#.

Storage Architecture


# Data Persistence All information about the database is stored in memory, with periodic writes to disk. Information is stored using write-ahead logging, with the option of also taking snapshots of the state of the entire system. When the system starts, this information is used to load the database into memory. If snapshots are being used, the most recent snapshot is loaded. Otherwise, the logged commands are replayed to restore the state of the database. The time needed to load the database is directly proportional to the size of the snapshot or the size of the logs, so the amount of time needed can increase significantly over time. # Disk Storage Options By default, data is stored in a user-specified directory in the file system. Each snapshot is stored as a single file. Logs begin with a single file, and more files are added as needed. The logs can also be stored as a relational database using MySql or OleDb. Some of the documentation indicates that there is also support for MongoDB, RavenDB, and Azure, but there is no support for these in the source code. However, users can define a custom `SqlStatements` object to use other databases. This option is not available for snapshots.

People Also Viewed

OrigoDB Logo


Source Code


Tech Docs



Devrex Labs

Country of Origin


Start Year


Project Type

Commercial, Open Source

Written in


Embeds / Uses


Operating Systems




People Also Viewed