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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.