SurrealDB is a multi-model DBMS that supports embedded and shared-nothing deployments. It uses a hybrid data model that combines documents with explicit graph edge relationships.[03]
- Website
- https://surrealdb.com[01]
- Source Code
- https://github.com/surrealdb/surrealdb[02]
- Tech Docs
- https://surrealdb.com/docs[03]
- @surrealdb
- Developer
- Country of Origin
- GB
- Start Year
- 2016 [11]
- Project Types
- Commercial, Open Source
- Written in
- Rust
- Supported Languages
- Go, JavaScript, Rust
- Embeds / Uses
- EchoDB, FoundationDB, RocksDB, TiKV
- Compatible With
- EchoDB, FoundationDB, RocksDB, TiKV
- License
- Business Source License
SurrealDB is a multi-model DBMS that supports embedded and shared-nothing deployments. It uses a hybrid data model that combines documents with explicit graph edge relationships.[03]
History[01]
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[04]
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.
Indexes
TBD
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[05]
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.
Logging
TBD
Parallel Execution[06]
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 Execution[07]
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[08]
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[09]
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[09]
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.
Stored Procedures[10]
SurrealDB provides constructs to store queries and functions in the database itself as futures. These queries/functions are executed whenever data is retrieved using the SELECT statements. Using these SurrealDB is able to support more functionality than just stored procedures.
Views
SurrealDB supports view using the TABLE construct which can define aggregate operations over other relations. These views/tables are stored as actual materialized tables in SurrealDB, and any updates to the tables are propagated so that the views are automatically updated.
Citations
13 sources- SurrealDB | The context layer for AI agents surrealdb.com
- GitHub - surrealdb/surrealdb: A scalable, distributed, collaborative, document-graph database, for the realtime web · GitHub github.com
- Getting started | SurrealDB Docs surrealdb.com
- DEFINE TABLE | SurrealDB Docs surrealdb.com
- Record links | SurrealDB Docs surrealdb.com
- https://github.com/surrealdb/surrealdb/blob/main/lib/src/dbs/iterator.rs github.com
- https://github.com/surrealdb/surrealdb/blob/main/lib/src/dbs/iterate.rs github.com
- https://surrealdb.com/docs/integration surrealdb.com
- https://github.com/surrealdb/surrealdb/tree/main/lib/src/kvs github.com
- Futures | SurrealDB Docs surrealdb.com
- https://www.linkedin.com/pulse/dreaming-something-better-surrealdb?trackingId=7cArqAk1EAsOH2sp706tuQ== linkedin.com
- https://github.com/surrealdb/surrealdb/commit/2bf9520f12969f21d1d9a9f0632b93a06c160502 github.com
- https://github.com/surrealdb/surrealdb/commit/ceb732878be46894485cf5257bf2da02a2823263 github.com