OneNoughtOne
0/278
Loading content...
Read aloud is unavailable in this browser.
For decades, the centralized database model served as the backbone of enterprise computing. A single powerful server housed all data, processed all queries, and maintained all integrity constraints. This model was elegant in its simplicity—one source of truth, straightforward administration, and well-understood semantics.
Yet this model is fundamentally inadequate for the modern world.
Today's applications serve billions of users across every continent. Financial transactions never sleep. Social networks span the globe. IoT sensors generate petabytes of data continuously. A single server—no matter how powerful—cannot meet these demands. The question is no longer whether to distribute, but how.
By the end of this page, you will understand the fundamental drivers behind distributed database systems—scalability, availability, performance, geographic requirements, and organizational needs. You'll grasp why centralized databases fail at scale and how distribution addresses each limitation systematically.
Before examining why we distribute, we must understand why centralization fails. A centralized database architecture places all data and processing on a single node or tightly-coupled cluster. While this offers simplicity, it encounters fundamental barriers as systems scale:
Physical Hardware Limits
No single machine can indefinitely scale vertically. CPU cores, RAM capacity, disk I/O bandwidth, and network throughput all have upper bounds. When your application needs 1 TB of RAM but the largest available server offers 512 GB, vertical scaling has failed. When your workload requires 10 million IOPS but your storage system peaks at 1 million, no amount of money solves the problem.
The Speed of Light
Physics imposes inflexible constraints. Light travels approximately 299,792 km/s in vacuum—about 200,000 km/s in fiber optic cables. A round trip from New York to Tokyo (approximately 21,500 km) takes at minimum 107 milliseconds just for light to travel. Add network equipment latency, and you're looking at 150-200ms minimum for any database operation. For interactive applications, this is unacceptable.
| Route | Distance | Light Speed Minimum | Typical RTT |
|---|---|---|---|
| Same Data Center | < 1 km | ~0.003 ms | 0.5 - 1 ms |
| Same Region | 100-500 km | 0.5 - 2.5 ms | 5 - 15 ms |
| Cross-Continental | 2,000-5,000 km | 10 - 25 ms | 40 - 80 ms |
| Transoceanic | 10,000-20,000 km | 50 - 100 ms | 150 - 300 ms |
Single Points of Failure
A centralized database is inherently a single point of failure. Hardware fails—disks, memory modules, power supplies, network cards, entire servers. Data centers experience outages from power failures, cooling failures, network cuts, and natural disasters. If your single database node fails, your entire application fails.
This creates an uncomfortable risk equation: the probability of any component failing increases with system complexity, yet centralization demands ever-more-complex single nodes. The more critical your system, the more catastrophic its failure.
As centralized systems grow more critical, they require more complex hardware for reliability. But more complex hardware has more failure modes. Eventually, the cost of achieving five-nines (99.999%) availability on a single node exceeds the cost of distributing across multiple simpler nodes—and distribution provides better availability anyway.
Scalability is the primary driver for database distribution. When a single machine cannot handle the workload, you have two options: make the machine bigger (vertical scaling) or add more machines (horizontal scaling).
Vertical Scaling (Scale Up)
Upgrade to more powerful hardware: faster CPUs, more RAM, faster storage, bigger network pipes. This approach is conceptually simple—your application code doesn't change, your deployment model stays the same. But vertical scaling has fundamental problems:
Horizontal Scaling (Scale Out)
Distribute data and processing across multiple machines. Each machine handles a portion of the overall workload. This approach addresses vertical scaling's limitations:
However, horizontal scaling introduces complexity:
These challenges define the distributed database design space. The motivation is clear—horizontal scaling is often the only viable path—but the implementation requires careful engineering.
Horizontal scaling is limited by the sequential fraction of your workload. If 10% of processing must happen sequentially, maximum speedup from parallelization is 10× regardless of node count. Distributed database design focuses on minimizing this sequential fraction through careful data partitioning and transaction scoping.
Availability measures the proportion of time a system is operational and accessible. For mission-critical applications—banking, healthcare, e-commerce, air traffic control—availability requirements approach 100%, often expressed as "nines":
Achieving high availability with a centralized database requires elaborate failure mitigation: redundant power supplies, redundant network paths, redundant disk controllers, standby nodes with synchronous replication. Despite this redundancy, centralization imposes limits.
Why Distribution Improves Availability
Distributed systems achieve availability through redundancy and independence. When data exists on multiple nodes:
The Mathematics of Redundancy
Consider a single node with 99.9% availability (8.77 hours downtime/year). If you replicate data across N independent nodes, and you only need one node available:
Of course, nodes aren't truly independent—correlated failures (shared network, shared power, shared software bugs) reduce these theoretical gains. But distribution still provides substantial availability improvement over centralization.
| Configuration | Individual Node Availability | System Availability | Downtime/Year |
|---|---|---|---|
| Single Node | 99.9% | 99.9% | 8.77 hours |
| 2 Replicas (independent) | 99.9% each | 99.9999% | 31.5 seconds |
| 3 Replicas (independent) | 99.9% each | 99.9999999% | 0.03 seconds |
| 3 Replicas (correlated, realistic) | 99.9% each | ~99.99% | ~52 minutes |
| 3 Replicas, 3 Regions | 99.9% each | ~99.999% | ~5 minutes |
Availability measures whether you can access data now. Durability measures whether data is preserved forever. They're related but distinct. A system might be temporarily unavailable (maintenance window) while perfectly durable, or available with durability risk (single replica, uncommitted data). Distribution typically improves both, but through different mechanisms.
Performance, particularly latency, drives distribution for globally-accessed applications. Users expect responsive applications regardless of their location. The speed of light imposes hard lower bounds on latency for distant data centers. Distribution solves this by placing data closer to users.
The Latency Problem
Consider an application serving users in both New York and Tokyo. With a centralized database in New York:
For a typical web page load requiring 5 database round trips:
This 30× difference creates dramatically inferior user experience for Tokyo users—directly impacting engagement, conversion, and satisfaction.
Geographic Distribution as Solution
By placing database replicas (or partitions) in multiple regions, you reduce the distance data must travel:
This approach trades consistency complexity for latency improvement. Data replicated across regions may be temporarily inconsistent (replication lag), requiring application-level design decisions about what consistency level each operation needs.
While reads can be served from local replicas, writes often require coordination. Synchronous replication across regions adds latency to every write. Asynchronous replication reduces write latency but creates consistency windows. This fundamental tension—between low latency and strong consistency—drives much of distributed database design.
Beyond technical motivations, organizational structures and regulatory requirements often mandate database distribution.
Organizational Autonomy
Large enterprises consist of semi-autonomous business units, each with distinct data management needs:
Distributed databases allow each unit to maintain local database instances while participating in organization-wide data integration when needed.
Data Sovereignty and Regulatory Compliance
Governments increasingly mandate that certain data remain within national borders:
A global company cannot simply store all data in one US data center. They need database architecture that places EU customer data in EU, Chinese customer data in China, and so forth—while still enabling unified analytics and operations where permitted.
| Regulation | Jurisdiction | Data Types Covered | Requirement |
|---|---|---|---|
| GDPR | European Union | Personal data of EU residents | Data processing must comply with EU law; international transfers restricted |
| Data Localization Law | Russia | Personal data of Russian citizens | Primary storage must be on Russian servers |
| Cybersecurity Law | China | "Important data" and personal information | Security assessment required for cross-border transfers |
| HIPAA | United States | Protected Health Information (PHI) | Specific security and privacy safeguards required |
| PDPA | Singapore | Personal data | Comparable protection required for transfers |
Data sovereignty requirements fundamentally shape distributed database design. You cannot simply optimize for performance and availability—you must also satisfy legal constraints. This often means maintaining separate database deployments per jurisdiction with controlled, audited data flows between them.
Counter-intuitively, distributing a database can reduce costs compared to centralized alternatives. While distribution adds operational complexity, it also enables cost optimization strategies that centralization precludes.
Commodity Hardware Economics
Distributed systems can use many inexpensive commodity servers instead of few expensive enterprise-grade machines:
If workload distributes well across 100 commodity servers at $15,000 each ($1.5M total) versus requiring a single $2M enterprise server, distributed architecture wins economically—and provides better availability and scalability.
Workload Isolation and Resource Optimization
Distribution enables workload isolation—separating different types of processing onto different infrastructure:
Centralized systems must provision for peak load across all workload types simultaneously. Distributed systems can right-size each component independently.
Cloud and Elasticity
Cloud computing platforms (AWS, Azure, GCP) charge by resource-hour. Distributed architectures can scale nodes up and down with demand:
Centralized architectures must provision for peak load continuously, paying for idle capacity during off-peak periods.
Distribution adds operational complexity that has costs: more nodes to monitor, more complex failure modes, specialized expertise requirements. A fair cost comparison considers total cost of ownership including operations, not just hardware. For many organizations, the scale and availability benefits justify these costs—but it's not universally cheaper.
Distribution is not universally appropriate. The complexity it introduces is substantial, and not every system benefits from—or can tolerate—that complexity.
Unnecessary Distribution
Many applications simply don't need distributed databases:
Complexity Costs
Distributed systems introduce failure modes that centralized systems don't have:
The "Distributed Systems Are Hard" Reality
Distributed systems require specialized expertise to design, implement, and operate. Failure modes are subtle and often emerge only at scale or under specific timing conditions. Teams without this expertise may achieve worse reliability with distribution than with a well-operated single-node database.
The pragmatic advice: Start centralized. Distribute when you must. Build your application with clean data access patterns that don't preclude distribution, but don't distribute until:
Premature distribution is a common mistake. Startups with 10,000 users don't need globally distributed databases. They need to find product-market fit. A single properly-tuned database instance can handle remarkable scale. Instagram famously served 30 million users on a small PostgreSQL deployment. Scale problems are good problems—they mean you have users.
We've examined the fundamental drivers that motivate database distribution. Let's consolidate these insights:
What's Next
Understanding why to distribute is the first step. The next question is how. In the following pages, we'll explore the fundamental techniques that distributed databases use:
Each technique addresses specific motivations—fragmentation for scalability, replication for availability, transparency for usability, and architecture for coherent system design.
You now understand the fundamental motivations driving database distribution. These aren't arbitrary technical choices—they're responses to real physical, organizational, and economic constraints. Next, we'll explore how data fragmentation partitions data across distributed nodes.