Loading field map
A distributed database is a collection of multiple, logically interrelated databases distributed over a computer network. The field of distributed databases studies how to store, query, and manage data across multiple machines in a way that appears to users and applications as a single, coherent database system. It sits at the intersection of database management and computer networking, inheriting the challenges of both: it must provide the familiar guarantees of a database—durability, consistency, and complex querying—while coping with the realities of distributed systems, such as network partitions, node failures, and variable latency.
The central problem of the field is a tension: distribution offers scalability, fault tolerance, and locality, but it fundamentally complicates the core promises of a database. A single-node database can enforce strong consistency easily because all data is in one place. Once data is spread across nodes, operations must coordinate over a network, and coordination is expensive, slow, and fragile. The field's history is largely a story of how researchers and engineers have navigated this trade-off, and its present landscape is defined by a spectrum of systems that make different choices along this axis.
To understand distributed databases, one must first understand the guarantees that a traditional database provides, typically summarized by the ACID properties: Atomicity (a transaction either commits completely or not at all), Consistency (a transaction brings the database from one valid state to another), Isolation (concurrent transactions do not interfere with each other), and Durability (once committed, a transaction's effects survive failures).
In a single-node database, these properties are enforced by a central transaction manager that can lock data, write logs, and roll back changes. In a distributed database, the same guarantees require coordinating multiple nodes. This coordination is governed by the CAP theorem, a foundational result from 2000 that states a distributed data system can provide at most two of three properties simultaneously: Consistency (every read returns the most recent write), Availability (every request receives a response, even if some nodes are down), and Partition tolerance (the system continues to operate despite network failures that split the system into isolated groups).
The CAP theorem is often misunderstood as a simple "pick two" choice. In practice, network partitions are not optional—they happen in any real distributed system—so the real choice is between Consistency and Availability when a partition occurs. A system that chooses Consistency will refuse to serve requests on the minority side of a partition to avoid returning stale data. A system that chooses Availability will serve requests from any node that can respond, even if that means returning data that may be outdated. This trade-off is not a one-time decision but a design philosophy that shapes every aspect of a distributed database.
The earliest research in distributed databases, from the 1970s through the 1990s, took the goal of a "single database image" literally. The aim was to build systems that were fully distributed—data partitioned and replicated across multiple sites—while preserving the full ACID guarantees of a centralized database. This approach is often called a distributed relational database or a homogeneous distributed database system.
The organizing assumption of this school was that distribution should be transparent. Users should be able to write SQL queries without knowing where data resides. The system's job was to hide the network. This required solving several hard problems:
The most influential research systems of this era were prototypes like System R* (an extension of IBM's System R), Distributed Ingres, and SDD-1. These systems demonstrated that distributed ACID databases were technically feasible, and they produced many of the algorithms still used today, such as distributed join algorithms and deadlock detection across nodes.
However, the classical approach had a fundamental limitation: it did not scale well. Synchronous replication and two-phase commit require a high degree of coordination, and coordination overhead grows with the number of nodes. A distributed database with ten nodes might perform acceptably, but one with a hundred nodes would spend most of its time coordinating rather than doing useful work. Moreover, the availability guarantee was poor: if any node in a transaction was unreachable, the entire transaction would fail. These systems were deployed in specialized settings, such as banking and airline reservation systems, where consistency was paramount and the number of sites was modest, but they never became the dominant form of database in the broader computing industry.
By the mid-2000s, a different set of pressures had emerged. Internet companies like Google, Amazon, and Facebook were operating at a scale that dwarfed traditional enterprise workloads. They needed to store petabytes of data, serve millions of concurrent users, and run across thousands of commodity servers. The classical distributed database, with its heavy coordination, could not meet these demands.
This period saw the rise of what came to be called NoSQL databases (the term originally meant "no SQL," later reinterpreted as "not only SQL"). These systems rejected the relational model and the ACID guarantees in favor of a simpler data model and weaker consistency, in exchange for massive scalability and high availability. The guiding philosophy was captured by the acronym BASE: Basically Available, Soft state, Eventual consistency. In this model, the system is always available to accept reads and writes, but replicas may temporarily diverge, and consistency is achieved only "eventually," once network partitions heal and background processes propagate updates.
The major NoSQL systems each made different design choices:
The NoSQL movement was not a single school but a family of related reactions against the constraints of relational databases. What united them was a shared set of assumptions: that the relational model's rigid schema was too inflexible, that ACID transactions were too expensive, and that horizontal scalability (adding more machines) was more important than strong consistency. They were willing to give up the "single database image" and instead expose the distributed nature of the system to the application developer, who had to reason about consistency and replication explicitly.
The trade-off was real: NoSQL systems could scale to thousands of nodes and remain available during network partitions, but they could not provide the transactional guarantees that many applications require. An application that needs to transfer money between two accounts, for example, cannot tolerate a system that might apply the debit but not the credit. The burden of correctness shifted from the database to the application, which had to implement its own consistency logic.
The pendulum began to swing back in the late 2000s and early 2010s with a movement that came to be called NewSQL. The goal of NewSQL was to provide the scalability of NoSQL systems while preserving the ACID guarantees and SQL interface of traditional relational databases. The insight was that the classical distributed database's scalability problems were not inherent to the relational model but rather to the heavy-handed coordination protocols it used.
NewSQL systems took several different approaches:
NewSQL systems demonstrated that ACID transactions and horizontal scalability were not mutually exclusive. However, they faced their own challenges. Strong consistency still requires coordination, and coordination has a cost. Spanner, for example, achieves remarkable consistency guarantees but requires specialized hardware (atomic clocks) and careful network engineering. CockroachDB and TiDB, which use a consensus protocol called Raft to replicate data, can provide strong consistency but with higher latency than a system that allows asynchronous replication.
The NewSQL movement did not replace NoSQL, nor did it replace classical distributed databases. Instead, it expanded the design space, showing that the trade-off between consistency and scalability was not a binary choice but a continuum. A system could choose strong consistency for some operations and weaker consistency for others, or it could provide strong consistency with acceptable performance by carefully optimizing the coordination protocol.
The present landscape of distributed databases is best understood not as a competition between rival schools but as a spectrum of systems that make different trade-offs along several dimensions. The most important dimension is consistency, but there are others: data model (relational, document, key-value, graph), replication strategy (synchronous vs. asynchronous), partitioning strategy (hash-based, range-based, or none), and deployment model (on-premises, cloud-native, multi-cloud).
At one end of the spectrum are systems that provide strong consistency (also called linearizability or external consistency). These include classical distributed databases, NewSQL systems like Spanner and CockroachDB, and some modern cloud databases like Amazon Aurora (which uses a quorum-based replication protocol). These systems are appropriate for applications where correctness depends on reading the most recent data, such as financial transactions, inventory management, and user account management.
At the other end are systems that provide eventual consistency, where replicas converge over time but may temporarily diverge. These include Dynamo-style key-value stores, Cassandra, and CouchDB. These systems are appropriate for applications where availability and scalability are paramount and where temporary staleness is acceptable, such as social media feeds, shopping carts, and analytics pipelines.
In between are systems that offer tunable consistency, allowing the application to choose the consistency level for each operation. Cassandra, for example, allows a write to be acknowledged after it has been written to one node, a quorum of nodes, or all nodes, and similarly for reads. This gives the application developer control over the trade-off, but it also places a burden on them to understand the system's behavior under different consistency levels.
Another important dimension is the replication model. Some systems use single-leader replication, where all writes go to one node (the leader) and are then propagated to followers. This simplifies consistency but creates a single point of failure and a bottleneck for write-heavy workloads. Others use multi-leader replication, where writes can go to multiple nodes, which improves availability but requires conflict resolution when concurrent writes to the same data occur. Still others use leaderless replication, where any node can accept writes and reads, and consistency is achieved through quorum protocols.
The modern landscape is also shaped by the rise of cloud databases. Major cloud providers offer managed distributed database services that abstract away much of the operational complexity. Amazon DynamoDB, Google Cloud Spanner, Azure Cosmos DB, and others provide distributed databases as a service, with automatic scaling, replication, and failover. These services often offer multiple consistency models and data models, allowing a single service to serve a wide range of applications. The cloud has also enabled multi-region deployment, where data is replicated across geographically distant data centers for disaster recovery and low-latency access, but this amplifies the challenges of network latency and partition tolerance.
Despite decades of research and development, several fundamental questions in distributed databases remain open or are being actively re-examined.
The cost of consistency remains the central trade-off. There is no free lunch: strong consistency requires coordination, and coordination costs latency and availability. The field has not found a way to eliminate this cost, only to manage it more efficiently. New protocols and techniques, such as deterministic transaction execution and conflict-free replicated data types (CRDTs), aim to reduce coordination overhead, but they do not eliminate the fundamental tension.
Distributed transactions remain hard. Two-phase commit is still the standard protocol, but its blocking problem (where a coordinator failure can leave participants uncertain) has motivated research into non-blocking protocols, such as Paxos commit and the use of consensus algorithms to implement transactions. These protocols are more complex and are only now being adopted in production systems.
Query optimization in distributed settings is more complex than in single-node databases because the cost model must account for network transfer, data locality, and the possibility of node failures. Modern systems use a combination of static optimization (based on statistics about data distribution) and dynamic adaptation (based on runtime measurements), but optimal query planning across a large cluster remains an open problem.
Schema evolution and data modeling in distributed systems is also challenging. In a single-node relational database, changing a schema is a well-understood operation. In a distributed database, a schema change must be propagated across all nodes, and it must not disrupt ongoing queries or transactions. NoSQL systems avoided this problem by making schemas optional, but this shifts the burden to the application and can lead to data inconsistency over time.
Security and privacy in distributed databases introduce additional complexity. Data is stored on multiple nodes, possibly in different jurisdictions, and must be encrypted both in transit and at rest. Access control must be enforced consistently across all nodes, and auditing must be able to reconstruct a coherent view of operations that may have occurred on different nodes at different times.
The field of distributed databases is not a settled discipline with a single accepted framework. It is a living area of research and engineering where the fundamental trade-offs are well understood but the optimal solutions for different application domains remain contested. The practical guidance for a developer or architect is not to ask "which distributed database is best?" but rather "what consistency, availability, and scalability properties does my application actually need?" The answer to that question determines where on the spectrum of distributed database designs one should look.