Is a replicated database necessarily partitioned?

No. Replication copies data, while partitioning divides it. A design may use either or both.

Can a distributed database provide strong transactions?

Yes, some do. The transaction scope, isolation level and failure assumptions must be checked for the particular system and configuration.

Does adding nodes always increase query speed?

No. It may add capacity, but query coordination, data movement, skew or a sequential stage can limit the benefit.

AI Glossary / Data engineering and architecture / Intermediate

Distributed database

Definition

A distributed database is a database whose data and database operations are managed across multiple networked nodes. It presents a coordinated way to store, query and update information while the underlying records, replicas or processing tasks occupy more than one machine.

What it means

The essential idea is a database service built from cooperating components. Data may be divided into partitions, replicated across nodes, or both. A user may see tables or documents without having to know which machine holds each record.

The degree of transparency varies. Some systems hide most placement details; others require developers to choose partition keys and understand restrictions on queries or transactions. A collection of unrelated databases does not automatically become one distributed database merely because they share a network.

Distributed databases can be relational or non-relational. Distribution does not dictate SQL support, a schema model or one consistency policy. It also does not mean every operation can continue during every failure. The system's documented guarantees determine what applications may safely assume.

How it works

When a request arrives, the database identifies the relevant data locations. A query may run entirely on one partition or combine work from several. An execution plan decides how to filter, join, aggregate and move intermediate results, within the system's supported operations.

Updates must follow the database's replication and transaction rules. A transaction spanning partitions can require coordination among their participants. Concurrency control determines how overlapping transactions interact; a commit protocol determines the supported all-or-nothing outcome across participants. These responsibilities are related but distinct.

The system also maintains placement information, handles failed nodes and may rebalance data. Replication can preserve service or data through specified failures, while backups address recovery needs that replicas alone cannot meet. Schema changes, index creation and maintenance also need coordination so components interpret records consistently.

Three practical examples

A subscription business keeps customer and account records in a distributed relational database while using defined transactions for updates that must remain consistent.
A messaging service partitions message records so storage and request volume can grow across machines, with a documented ordering and visibility model.
An analytics platform distributes query processing over large datasets, combining partial results while users work through a common database interface.

Think of it this way

Think of a records service with several offices and a shared set of filing and update rules. A request may be answered by one office or require several to cooperate. The customer sees a service, while staff coordinate where records reside and which changes are final.

The analogy does not imply that all offices hold identical copies or that communication is instantaneous. Those are precisely the choices a distributed database must define.

Worked example

Suppose a fictional reporting table has 900,000 records, divided equally across three partitions. A query asks for the overall average processing time. Each partition can return its count and sum rather than sending every record to a coordinator.

If the partitions return counts of 300,000 each and sums of 1,200,000, 1,500,000 and 2,700,000 seconds, the global average is 5,400,000 divided by 900,000: 6 seconds.

Now suppose a filter produces different counts on each partition. Simply averaging the three local averages would generally be wrong; the coordinator needs counts and sums, or equivalent weighted information. Distribution changes where calculation happens, but it must preserve the meaning of the query. The example ignores data-transfer and coordination overhead and assumes all partial results belong to the intended database view.

Illustrative case study

Fictional case: a rental business considers a distributed database because records and traffic have outgrown its current setup. Most customer lookups are local to one region, while some transfers affect equipment records in two regions.

The evaluation separates these access patterns. It measures local lookups and cross-region transactions, checks retry behavior, and confirms the isolation needed to prevent incompatible reservations. It also runs a restore exercise after an intentional test-data deletion.

A proposed partition key is revised when tests show that one large customer creates uneven load. The final evaluation describes placement, correctness and recovery together. No specific cost or speed gain is claimed; the scenario shows why a successful migration depends on workload fit, not merely the availability of additional nodes.

Common misconceptions and mistakes

A common mistake is assuming a familiar query language makes distribution invisible to performance. A join or transaction spanning distant partitions may cost more than one confined to a single location.

Other mistakes include believing all distributed databases are eventually consistent, treating replication as protection against every logical error, and comparing systems without specifying isolation and durability settings. Strong transactional guarantees are possible in distributed designs, but they depend on defined protocols and assumptions. A product's configured mode matters as much as its broad category.

Business use

For a business, the relevant questions concern growth, geographic access, recovery and correctness. Identify which operations must be atomic, which reads need fresh information and which queries touch many partitions. Evaluate these operations under realistic data skew and contention.

For AI applications, the database might manage prompts, retrieval metadata, job state or evaluation records. These uses have different transaction and query requirements. A large distributed database does not automatically make an AI answer accurate; source quality, permissions and application logic remain separate concerns.

Check your understanding

Three partitions return averages for groups containing different numbers of records. Can a coordinator obtain the overall average by taking the simple mean of those three averages?

Answer: Generally no. It needs appropriate weighting, such as combining each partition's sum and count. The correct database result must preserve the original query's arithmetic.

Related terms

Distributed data store
Replication (statistics)
Distributed transaction
Isolation (database systems)
partitioning
replication
distributed query processing
isolation
query plan
data locality

Learn next

study partition keys and distributed query plans to understand placement costs. Then examine concurrency control and atomic commit to understand cross-partition updates. Use one representative business query and one critical update as running examples.

Concurrency control

Sources

Corbett and colleagues, Spanner: Google's Globally-Distributed Database: https://research.google/pubs/spanner-googles-globally-distributed-database-2/ . Primary research overview demonstrating distributed transactional design. Google Cloud, Life of Spanner Reads and Writes: https://docs.cloud.google.com/spanner/docs/whitepapers/life-of-reads-and-writes . Primary implementation account of partition routing, replication and transaction coordination; these mechanisms are examples, not universal requirements. Bacon and colleagues, Spanner: Becoming a SQL System: https://research.google/pubs/spanner-becoming-a-sql-system/?hl=id . Primary research abstract on distributed query execution.

Previous: Distributed data store Next: Distributed file system for cloud