History[04]

The work on SurrealDB was started in 2016 by Tobie and Jamie Morgan Hitchcock as a private project. The first functional version of SurrealDB was completed in 2017 and it was written completely in Go. In 2021, the source code for the SurrealDB project was made public to allow contributions from the outside world. Work on building an improved version of SurrealDB with Rust from scratch also begin in 2021. In 2022, SurrealDB was released in public beta mode.

Checkpoints[02]

SurrealDB does not explicitly support checkpoints. However, SurrealDB internally uses other key-value store databases for storing user data and metadata in the backend. Some of these backends like RocksDB do support checkpointing and might create checkpoints in the background.

Compression

SurrealDB does not use any compression techniques since SurrealDB does not have its own storage layer. It instead relies on the other key-value storage databases in the backend to store all user data and metadata. These key-values databases can then use any supported compression techniques for the data that is pushed to them.

Concurrency Control[02]

SurrealDB does not implement any concurrency control when operating on the data. However, all operations done by SurrealDB as a part of a query are encapsulated in a transaction. These transactions are transactions on the underlying back-end key-value store databases. Therefore SurrealDB is able to achieve various types of concurrency control depending on the concurrency control provided by the back-end databases.

Data Model[05]

SurrealDB supports relational, document, and graph-based data models. By default, SurrealDB creates schema-less documents, however the SurrealQL syntax provides functionality for creating fixed-schema tables as well. Graph-based models are constructed by representing the nodes and the edges as relations that are related by record links.

Foreign Keys

SurrealDB does not have the concept of foreign keys. It instead uses record links to link records in different relations like the edges of a graph.

Hardware Acceleration

SurrealDB does not have any hardware acceleration support in-built.

Isolation Levels

SurrealDB does not implement isolation across transactions by itself. Since it uses other key-value databases to store data, it can provide the same isolation level that the back-end databases are able to support.

Joins[06]

SurrealDB does have the concept of joins. Instead of Joins between pre-defined relations, SurrealDB uses graph edges (record links) to link records to each other. With graph edges and the ability to store arrays and objects as field members, SurrealDB can provide the functionality of Joins along with other graph-based operations like path traversal.

Parallel Execution[07]

SurrealDB allows a PARALLEL keyword to be added to most queries. This allows SurrealDB to spawn multiple threads to execute fetch and update operations. Using this SurrealDB is able to fetch data form relations in parallel by spawning one thread per relation. Further it is able to run the insert/update/delete operations for each row in parallel since it uses a row-by-row iteration model.

Query Compilation[02]

SurrealDB does not have support for query compilation.

Query Execution[08]

SurrealDB uses the volcano-style tuple-at-a-time model for query execution. However, while loading the data from the storage, SurrealDB tries to amortize the IO cost by loading 1000 data points at a time and then processing them one at a time as per the query requirements.

Query Interface[09]

SurrealDB can be started as an independent process or embedded in the application as a library. As an independent process, it is possible to interact with the database using either the SurrealQL REPL (if SurrealDB is running locally), or using the HTTP/REST endpoints. As a library, SurrealDB can be used in other applications by interfacing with the APIs provided by the SurrealDB library. SurrealDB also provides the WebSocket API which can be interfaced with using RPCs.

Storage Architecture[10]

SurrealDB can support 3 types of storage architectures: in-memory; on-disk; and distributed cloud. Since SurrealDB uses other key-value store databases to provide storage functionality, it is able to take advantage of all storage architectures supported by those key-value stores. Currently, the in-memory mode is supported using EchoDB. on-disk mode is supported through databases like RocksDB, and distributed cloud storage is supported by databases like TiKV.

Storage Format

SurrealDB uses a rust package called serde for serializing and deserializing data. It defines its own serialization and deserialization formats for some of its types and relies on the default serializer in serde for all other types.

Storage Model[10]

SurrealDB does not implement its own storage layer. It relies on other key-value store databases to provide storage functionality for the user data and metadata. However, SurrealDB can only support key-value stores as the storage layer. All data in SurrealDB is eventually stored in the key-value format after internal processing.

Storage Organization

Stored Procedures

System Architecture