Today, alongside SurrealDB 4, we’re introducing SurrealDS, a new distributed storage engine for SurrealDB backed by object storage, designed for elastically scalable, fault-tolerant deployments across multiple nodes and availability zones.
Available as part of new SurrealDB Cloud multi-node clusters and SurrealDB Enterprise Edition for self-hosted deployments, SurrealDS separates database compute from durable storage.
Each SurrealDB node keeps a fast local working set, while persistent data is stored in shared object storage: Amazon S3 and S3-compatible stores, Azure Blob Storage, or Google Cloud Storage.
The result is an architecture designed to combine local performance with the durability, scalability, and operational characteristics of object storage.
Why did we build SurrealDS?
Running a database on one machine is relatively straightforward. Running it reliably across machines and availability zones introduces a different set of problems.
A distributed database needs to answer questions such as:
When can a write safely be acknowledged?
What happens when a node fails during a write?
How does another node take over without serving stale data?
How do nodes agree on the order of transactions?
How do you recover from failure without copying the entire database between machines?
How do you scale compute and storage independently?
Our new distributed engine is designed around these problems.
Rather than treating a database node and its disk as a single unit, it separates the durable data layer from the compute processes executing SurrealQL. This gives SurrealDB a storage architecture designed for distributed cloud environments where compute can be added, removed, or replaced independently of the underlying data.
Local performance, shared durable storage
Each node works across three storage tiers:
Memory for the hottest data and active transactional state.
Local disk for the commit log and caching.
Shared object storage for durable database pages and long-term storage.
Queries therefore do not need to fetch every piece of data from object storage. Frequently accessed data can remain close to the database process, while the durable representation of the dataset lives independently of any individual node.
This also removes the need for every compute node to maintain its own complete copy of the database.
Elastically scalable compute and storage
Traditional distributed databases often tie compute capacity to storage capacity. If you need more compute, you add another database node. That node often comes with another full replica of the data, whether or not you actually need additional storage.
By using shared object storage as the durable data layer, SurrealDB can scale these dimensions more independently. Compute capacity can be increased by adding nodes to serve additional workloads, while the underlying dataset remains in shared storage.
Likewise, storage can continue growing without requiring a corresponding increase in the number or size of database nodes. This architecture forms the basis for elastic scaling in SurrealDB Cloud multi-node clusters, where infrastructure can adapt to changing workloads without treating every node as a permanent holder of the full dataset.
Writes are ordered before they are acknowledged
Within a distributed deployment, writes are placed into an ordered commit log. One node is responsible for sequencing writes for a given scope. Each transaction receives a position in that sequence before it becomes part of the durable state of the database.
In a multi-zone deployment with the default policy, a write is acknowledged only after it is durable on the sequencing node and on a second node in another availability zone. If no such node is available, the write is refused rather than acknowledged on a single copy. Under that policy, an acknowledged write has been retained across two failure domains.
Other nodes follow the same ordered log and maintain a consistent view of committed state.
Reads without routing everything through one node
Many distributed database architectures route writes through a leader and then send consistency-sensitive reads through that same node. SurrealDB takes a different approach.
Every node runs the database engine and can serve queries. Reads are checked against the point in the ordered log that the node has observed. Data pages carry the log position they represent. If nothing relevant has changed since that point, the existing value can be returned. If newer changes exist, those changes are incorporated before the result is served.
This allows nodes to serve consistent reads without requiring all read traffic to pass through a single coordinator. Transactions operate against a pinned snapshot and validate their read set when they commit. The engine provides serializable isolation within a scope. Through SurrealDB, transactions run at snapshot isolation by default, with serializable isolation available as an option.
From the commit log to durable database pages
The commit log handles recent changes, but it is not intended to grow indefinitely. The engine periodically folds accumulated changes into a copy-on-write tree and publishes a new root representing the database at that point in time.
The resulting pages are content-addressed. If a page has not changed between two versions of the database, both versions can reference the same underlying page instead of storing another copy.
This means unchanged data does not need to be rewritten whenever a new database state is published, and historical roots can share the same underlying storage.
Because those pages live in object storage, the durable database state is also independent of the lifecycle of an individual compute node.
Built for node and zone failure
Distributed infrastructure eventually fails. Processes crash. Disks become unavailable. Networks partition. Availability zones can disappear temporarily. The distributed engine is built around explicit recovery from these conditions.
A production deployment can run nodes across multiple availability zones. The system tracks which node is responsible for sequencing transactions and which other node holds the second durable copy of acknowledged writes. If the active node becomes unavailable, another node can take ownership through a coordinated succession process.
Before serving in its new role, the group verifies the required state and repairs missing data where necessary. A key principle is that the database should not return a plausible but potentially incorrect result simply because the cluster is unhealthy. Where correctness cannot be established, the operation is refused rather than serving data from the wrong state or point in time.
Object storage as the durable layer
Using object storage changes how distributed database infrastructure can be designed. Traditional architectures commonly maintain several full copies of a dataset on attached disks. That provides redundancy, but it also means storage consumption increases with the number of database nodes.
With SurrealDB's new architecture, durable database pages live in shared object storage instead. Compute nodes maintain the local logs, caches, and state required for low-latency operation, while the complete durable dataset exists independently in the shared storage layer. Replacing a compute node therefore does not mean replacing one of the only authoritative copies of the database. It also makes long-term storage capacity less dependent on the shape of the compute cluster.
Kubernetes-native deployment
The new distributed engine is designed for multi-node SurrealDB deployments on Kubernetes. A typical deployment places nodes across availability zones, with each node running its own SurrealDB process and local persistent volume while sharing the same object store.
The SurrealDB Operator manages the surrounding infrastructure, including:
Availability-zone placement
Persistent volumes for local logs
Peer configuration
Services and routing
TLS between nodes
Readiness and liveness checks
Disruption budgets
Rolling configuration changes
Deployment strategies for version upgrades
Nodes communicate over authenticated peer connections, while applications continue interacting with SurrealDB through the normal database interface. The distributed storage architecture therefore remains largely transparent to the application.
Safer distributed upgrades
Upgrading a distributed stateful system requires more than replacing containers one at a time. SurrealDB and the SurrealDB Operator determine whether a version change can safely happen as a rolling upgrade or whether the deployment needs a coordinated restart.
Compatible versions can roll node by node while the group continues serving traffic. Where storage or communication formats are incompatible, the deployment can instead perform a controlled stop-and-start process rather than allowing incompatible nodes to participate in the same group.
The operator reports the deployment's phase through the resource's Kubernetes status: deciding, rolling, stopping, starting, serving, refused or failed.
Tested around failure, not just normal operation
Distributed storage is difficult to validate through unit testing alone. The engine is tested using several complementary methods.
Deterministic simulation testing exercises storage and recovery across thousands of reproducible failure scenarios, including message loss, network delays, partitions, disk failure, and interrupted recovery.
Formal models are used to verify core distributed protocols and invariants.
Fault-injection testing runs real multi-node deployments while deliberately disrupting nodes, disks, and network paths, with more scenarios being added.
Performance testing also includes deliberately broken variants of the system to confirm that benchmarks actually measure the property they claim to measure. The goal is not simply to prove that a healthy cluster works. It is to validate how the system behaves when parts of the infrastructure fail.
A new foundation for distributed SurrealDB
SurrealDB now has storage engines designed for different deployment requirements.
SurrealKV provides high-performance persistent storage on a single node.
SurrealMX provides in-memory storage for workloads where minimum latency is the priority.
SurrealDS, a separate engine from both, provides elastically scalable, fault-tolerant storage backed by object storage for deployments spanning multiple machines and availability zones. It combines ordered transactions, local caching, shared object storage, multi-zone durability, consistent reads, and coordinated recovery into a storage architecture designed specifically for SurrealDB.
It is available through SurrealDB Enterprise Edition and already runs new SurrealDB Cloud multi-node clusters. For applications, the database remains the same: SurrealQL, the same multi-model capabilities, and the same client interfaces. What changes is the architecture underneath it.
Want to try it? Contact us to get started or read the documentation to learn more.
