What Is a Distributed Database? Architecture & Migration Guide

A distributed database is a database system in which data is stored, processed, and managed across multiple servers or nodes—often spread across different data centers or geographic regions—rather than residing on a single machine. This architecture allows the system to scale horizontally, remain available even when individual components fail, and support far higher transaction volumes than a single-server system ever could.

To an application, a distributed database still behaves like one logical database: the same SQL syntax, the same transactional guarantees, the same query patterns. But behind that interface, the system is coordinating dozens, hundreds, or even thousands of physical nodes, routing requests, replicating data, and keeping every copy consistent in real time.

A centralized, or traditional, database keeps all of its data on a single machine, or a primary machine with passive replicas. When that machine runs out of capacity, the only way to scale is "vertically"—adding more CPU, memory, or storage to the same server. There is a ceiling to how far this can go, and a single point of failure sits underneath the entire system. A distributed database removes that ceiling by scaling "horizontally": adding more machines to the cluster rather than making one machine bigger, and spreading both data and workload across all of them.

OceanBase is one of the typical examples of this approach done well. It was built from its very first line of code as a natively distributed relational database, not as a traditional single-node engine with distribution features layered on top later. That distinction—native versus retrofitted—turns out to matter a great deal, and it is worth understanding why.

This is one of the most common points of confusion in the industry, so it is worth addressing directly.

Database sharding is a technique for splitting a single logical database into smaller pieces, or "shards," which are then distributed across multiple servers—typically coordinated by an external middleware layer sitting on top of otherwise ordinary, unmodified database instances. Each shard is usually a standalone database with no built-in awareness that it is part of something larger. The middleware handles routing queries to the right shard, and when a transaction needs to touch data in more than one shard, the middleware also has to stitch together some form of distributed transaction logic—often through compensating transactions bolted on from outside.

A native distributed database, such as OceanBase, builds all of this coordination directly into the database kernel itself. In practice, that means cross-shard transactions carry full ACID guarantees natively rather than relying on fragile, application-level compensation logic; adding or removing capacity is transparent to the application, with no re-sharding script to rewrite; and data consistency across nodes is enforced by a consensus protocol, such as Paxos, at the storage layer rather than stitched together after the fact.

Sharding is a workaround, applied after the fact, for scaling a database engine that was not designed to be distributed. A native distributed database like OceanBase is engineered for this outcome from day one. The difference becomes especially visible under real pressure—during a large-scale promotional sale, a product launch, or a sudden traffic spike—when sharded architectures are considerably more prone to cross-shard transaction failures, while a natively distributed engine keeps performing as one coherent system.

For decades, a single powerful server running a traditional relational database was enough for most businesses. That is no longer true for a large and growing share of the economy. Three pressures, in particular, have pushed distributed databases from a specialized system into a mainstream infrastructure decision.

The first is capacity. Digital businesses—fintech apps, e-commerce platforms, gaming studios, telecom operators—now generate data volumes and transaction rates that a single machine simply cannot absorb, no matter how much hardware is thrown at it. Vertical scaling runs into physical and economic limits long before demand does.

The second is concurrency. Modern applications don't just store more data; they also need to serve far more simultaneous users and transactions, often with sub-second latency expectations. A flash sale, a viral social moment, or a national shopping event can multiply normal traffic by an order of magnitude within minutes, and the underlying database has to absorb that surge without buckling.

The third is resilience. A single-machine database is, by definition, a single point of failure. As more of the world's commerce, banking, and public services move online, the cost of downtime—financial, reputational, sometimes regulatory—has risen sharply. Businesses increasingly need systems that keep running through hardware failures, network partitions, and even the loss of an entire data center.

This shift is not limited to legacy industries retooling their existing infrastructure. A new generation of digital-native businesses—companies built entirely on cloud infrastructure from their very first day of operation—are choosing distributed databases as their default starting point rather than a later-stage migration. For these organizations, the question is rarely whether to eventually adopt a distributed architecture, but which one to build on from the outset.

These pressures show up clearly in market trends: enterprises across finance, retail, telecom, and the public sector are steadily replacing legacy, single-node database architectures with distributed alternatives, and analysts covering the database market have consistently pointed to distributed and cloud-native database architectures as one of the fastest-growing segments of enterprise IT spending.

OceanBase was built specifically in response to this kind of pressure. It originated inside one of the world's largest real-time payment environments, Alipay, where transaction volumes and availability requirements left no room for the traditional trade-offs between scale, consistency, and cost. That origin story shapes the product to this day: OceanBase is designed to absorb extreme peak concurrency without sacrificing transactional correctness, and to do so at a cost profile that does not require proprietary high-end hardware.

To understand how a distributed database works, it’s important to understand several core architectural principles. These principles are what distinguish a truly distributed database from a collection of separate databases connected through middleware.

At the heart of any reliable distributed database is a consensus algorithm—a rigorous protocol that allows multiple independent nodes to agree on the state of the data, even when some nodes are slow, unreachable, or have failed outright. The best-known family of these protocols is Paxos, originally described in distributed-systems research and since adapted by major database and infrastructure providers worldwide.

In practice, consensus protocols work by requiring a majority of replicas to acknowledge a write before it is considered committed. This means the system can tolerate the loss of a minority of nodes—say, one out of three, or two out of five—without losing data or pausing service. OceanBase implements its own optimized Paxos-based consensus protocol, which is what allows it to guarantee zero data loss, or RPO = 0, even through node failures, rack failures, or the loss of an entire availability zone. This same mechanism also protects against a subtler failure mode known as split-brain, where a network partition could otherwise cause two separate groups of nodes to each believe they are the legitimate leader; requiring majority agreement makes that scenario mathematically impossible.

A related but distinct concept is multi-active architecture: the ability to run multiple data centers simultaneously, all actively serving live traffic, rather than keeping secondary sites idle in a passive standby role. This is sometimes described as multi-IDC, or multiple Internet data center, deployment.

The advantage is twofold. First, it makes far better use of infrastructure investment, since every data center is doing productive work rather than waiting for a disaster that may never come. Second, it dramatically shortens recovery time when something does go wrong, because traffic can shift to an already-warm, already-serving data center rather than waiting for a cold standby to spin up. OceanBase supports multi-active deployment across data centers, cities, and even geographic regions, using the same underlying consensus mechanism to keep every active site consistent.

Horizontal scaling is the defining trait of a distributed database: the ability to add capacity by adding more machines, rather than by making an existing machine bigger. This scaling is elastic—capacity can be added or removed to match real demand, without downtime and without requiring the application layer to be rewritten.

OceanBase's architecture separates compute and storage responsibilities inside the cluster, which allows new nodes to be added and data to be automatically rebalanced across the cluster with no interruption to running workloads. This means a business can provision for its average load rather than its theoretical peak, and scale out temporarily to absorb a seasonal spike, then scale back down once demand normalizes. Because scaling decisions are made at the cluster level rather than requiring changes to how the application connects to the database, engineering teams can respond to a capacity need in minutes rather than planning around a lengthy hardware procurement or re-architecture cycle.

Perhaps the hardest engineering problem in distributed databases is preserving full ACID guarantees—Atomicity, Consistency, Isolation, Durability—when a single transaction might touch data spread across many physical nodes. Many early distributed systems solved scale by sacrificing some of these guarantees, offering eventual consistency instead of strict transactional correctness. That trade-off is unacceptable for financial transactions, inventory systems, or anything where correctness matters more than raw throughput.

OceanBase was engineered specifically to avoid this trade-off. It supports full distributed ACID transactions natively, using its own distributed transaction protocol built on top of its Paxos-based consensus layer, so that a transaction spanning multiple nodes is still guaranteed to be atomic and strongly consistent, with no partial writes and no silent data drift between replicas.

For any system handling business-critical transactions, availability is not a nice-to-have; it is the entire point. Two metrics anchor most conversations about availability and disaster recovery: RPO and RTO.

Recovery Point Objective, or RPO, measures how much data, if any, a business could lose in the event of a failure. The RPO of zero means no data loss is acceptable, or achievable, under any failure scenario. Recovery Time Objective, or RTO, measures how long it takes the system to resume normal operation after a failure. The tighter both numbers are, the more resilient—and more expensive to achieve—the system tends to be.

Distributed databases achieve near-zero data loss primarily through synchronous, majority-based replication: a write is not confirmed as committed until it has been durably recorded on a majority of replicas, typically spread across different racks, data centers, or regions. If one replica is lost, the data still exists intact on the others, and the consensus protocol elects a new leader among the surviving replicas automatically, without manual intervention.

Multi-region, multi-active disaster recovery models extend this same principle across greater distances, protecting against larger-scale failures—an entire data center losing power, a regional network outage, or a natural disaster—by keeping fully independent, geographically separated copies of the data all actively serving traffic.

Consider what this looks like in practice for a business running infrastructure across three data centers. If one center loses power entirely, a distributed database with RPO = 0 and automatic failover will have already redirected traffic to the surviving centers before most engineering teams even receive an alert, with every previously committed transaction intact. Compare that to a traditional standby architecture, where an operator may need to manually promote a backup and redirect application traffic, a process that can take minutes or hours rather than seconds.

OceanBase's architecture is built to deliver on both ends of this equation at once: it targets RPO = 0, meaning zero data loss under standard failure scenarios, alongside an industry-leading RTO of under 8 seconds for automatic failover. In practical terms, a server failure, a rack failure, or even the loss of an entire availability zone can be absorbed with the cluster continuing to serve traffic, automatically and within single-digit seconds, with no data lost in the process.

Distributed databases are not an abstract architectural preference; they solve concrete problems for specific industries, each with its own combination of scale, correctness, and availability requirements.

Financial institutions and fintech companies operate under some of the strictest correctness and availability requirements of any industry. A payment that is double-processed, a balance that is briefly inconsistent across replicas, or a system that goes down during market hours is not just an inconvenience; it can be a regulatory incident. This is precisely the environment financial-grade distributed databases like OceanBase were built for: full ACID guarantees on every transaction, zero tolerance for data loss, and the ability to keep serving requests through hardware failures without human intervention. OceanBase's origins inside one of the world's largest real-time payment platform, Alipay, mean its architecture has been stress-tested for years against exactly these conditions, at a transaction volume most databases never encounter. For a bank or a fintech platform evaluating new infrastructure, that track record matters more than any lab benchmark, because it reflects performance under the kind of sustained, adversarial, real-money conditions that are difficult to simulate in a test environment.

Retail and e-commerce platforms face a distinctive challenge: traffic that is wildly uneven, with ordinary days followed by promotional events that can multiply load by ten times or more within minutes. Gaming platforms face a similar pattern around new releases and live events, while digital-native businesses—apps and platforms built entirely in the cloud from day one—often need to scale unpredictably as they grow. In all of these cases, the database has to absorb sudden, extreme concurrency without slowing down or losing transactional accuracy, since a failed checkout, a duplicated in-game purchase, or an inconsistent inventory count directly costs revenue and trust. OceanBase's elastic, horizontally scalable architecture is specifically suited to this kind of workload; it has handled the Double Eleven Shopping Festival, the highest-concurrency shopping events in the world, and its multi-tenant design lets a single cluster serve many applications or business units while still isolating their workloads from one another, which is particularly useful for digital-native companies running many product lines on shared infrastructure.

Telecom operators run some of the highest-volume transactional systems anywhere, processing enormous numbers of billing events, call detail records, and account updates continuously, around the clock, across huge subscriber bases. These systems need both the raw throughput to keep up with constant transaction volume and the strict consistency to make sure every customer is billed accurately. OceanBase's combination of horizontal scalability and native distributed transactions has made it a strong fit for large telecom billing and charging platforms that need to modernize away from aging, hard-to-scale legacy database infrastructure.

Government and public-sector systems bring a distinct set of requirements: strict data sovereignty and compliance obligations, high public accountability for uptime, and often a need to serve very large populations through a single platform. Distributed databases give public-sector organizations a way to meet these requirements without depending on a single vendor's proprietary hardware or a single point of failure. OceanBase's support for flexible, on-premises, and multi-cloud deployment models has made it a practical choice for government cloud platforms seeking both resilience and independence from legacy proprietary database vendors.

Across every one of these industries, the underlying requirement is fundamentally similar: the ability to handle growing, often unpredictable transaction volume while preserving strict correctness and staying available through failure. What differs is only the specific regulatory, latency, or scale profile each sector demands, which is why a flexible, natively distributed architecture, rather than a narrowly specialized one, tends to serve all of them well.

Every enterprise running a legacy, single-node relational database eventually confronts the same question: modernize, or keep paying the rising cost of staying put. That cost shows up in several ways—expensive proprietary licensing tied to a single vendor, hardware that has to be replaced as a large, disruptive project rather than an incremental upgrade, and a growing gap between what the business needs and what the aging architecture can deliver. This has led a growing number of enterprises to actively reduce their dependency on proprietary, vendor-locked database platforms in favor of open, horizontally scalable alternatives.

A well-run migration typically follows a clear roadmap: an assessment phase, where existing schemas, queries, and application dependencies are audited for compatibility; a pilot phase, where a non-critical workload is moved first to validate performance and correctness under real conditions; and a cutover phase, where the production workload is moved over, often using dual-write or replication techniques to keep both the old and new systems synchronized until the transition is verified and complete.

Beyond the technical roadmap, the business case for migration usually centers on three factors: reducing total cost of ownership by moving away from expensive proprietary licensing models, removing the ceiling on future growth that a single-node architecture eventually imposes, and reducing operational risk by eliminating single points of failure that a legacy system cannot easily distribute across nodes or regions. For most enterprises, the migration decision is driven less by any single dramatic outage and more by the accumulating weight of these three pressures over time.

The most common challenges in this process are SQL dialect compatibility, ensuring existing queries and stored procedures behave identically on the new platform, and performance validation, making sure the new system meets or exceeds the old one under real production load rather than synthetic benchmarks alone. OceanBase addresses the first of these directly through high compatibility modes for both MySQL and Oracle syntax, which significantly reduces the amount of application code that needs to be rewritten, and it provides dedicated migration tooling to support schema conversion, data synchronization, and validation throughout the cutover process.

Architecture claims are only as credible as the benchmarks that back them up, and in the database industry, the most widely recognized of these is TPC-C: an industry-standard test administered by the Transaction Processing Performance Council that measures how many new-order transactions per minute, or tpmC, a system can sustain under a realistic, mixed transactional workload. Because the test methodology is standardized and independently audited, TPC-C results allow for genuine, apples-to-apples comparison across vendors and architectures.

OceanBase stands alone as the world's only distributed database to set world records on both the TPC-C and TPC-H benchmarks. In 2019, it shattered the TPC-C world record for online transaction processing with a performance of 60.88 million tpmC. Just one year later, in 2020, it raised the bar again, achieving an astounding 707 million tpmC. Then, in 2021, OceanBase conquered the analytical workload benchmark, TPC-H, claiming the top spot with a score of 15.26 million QphH@30000GB. These dual world records are a powerful testament to OceanBase's capability to deliver extreme performance, high availability, and linear scalability for both OLTP (Online Transactional Processing) and OLAP (Online Analytical Processing) workloads. This validates its superior architecture for the most demanding hybrid transactional and analytical processing (HTAP) environments.

It is worth noting what these benchmark numbers actually represent in practice. The 707 million tpmC result was not achieved on a single powerful machine; it was demonstrated across a distributed cluster of more than 1,500 servers, which is itself the point: a properly engineered distributed database does not just tolerate scale, it is specifically designed to convert additional hardware into additional throughput in a close-to-linear fashion, something a traditional single-node architecture simply cannot do no matter how much hardware is added to it.

These numbers matter as evidence of a broader point: distributed architecture, done correctly, does not require trading away raw performance for scalability and resilience. A well-engineered distributed database can outperform traditional single-node systems even on their own historical benchmark, while adding the availability and elasticity that single-node systems simply cannot offer.

For an evaluator comparing platforms, the more useful question is usually price-for-performance rather than the headline benchmark number alone: how many transactions a given architecture can sustain per dollar of infrastructure spend, and how that ratio holds up as workload grows. Because OceanBase runs efficiently on commodity hardware rather than requiring specialized, high-end servers, its benchmark results tend to translate into a meaningfully lower total cost per transaction at scale compared with traditional proprietary database platforms.

As a native distributed database, OceanBase delivers exceptional performance in scalability, high availability, and data consistency, thanks to its unique architecture and underlying technologies. Here’s a detailed look at how OceanBase achieves this:

OceanBase is built on a Shared-Nothing distributed architecture where all data nodes (OBServers) are peers. Each node has its own independent SQL engine, storage engine, and transaction engine, running on a cluster of commodity servers. This design provides immense horizontal scalability.

Furthermore, this peer-to-peer architecture inherently supports parallel computing across multiple machines, enabling it to scale up to petabyte-level capacity. This effortlessly provides a stable storage foundation for an enterprise's entire data landscape.

OceanBase utilizes a data storage structure based on the Log-Structured Merge-Tree (LSM-Tree), continuously optimized for high-concurrency transactional processing (TP). This architecture enhances performance in scenarios involving random writes, real-time updates, and strong consistency requirements.

Simultaneously, the LSM-Tree's layered merging and static data organization make it a natural fit for Online Analytical Processing (OLAP) workloads, which are characterized by batch writes and infrequent updates. Through features like columnar data compression, hierarchical merge strategies, and storage fragmentation optimization, it not only meets the efficient scanning demands of analytical workloads but also provides a unified architecture to support hybrid transactional and analytical processing (HTAP) workloads.

OceanBase uses the Paxos protocol to achieve strongly consistent, synchronous persistence of Commit Logs (Clog) across a majority of replicas. Within a Paxos group, even if a minority of replicas fail, the remaining majority ensures they hold the latest Clog. This prevents data loss from individual hardware failures and guarantees strong data consistency and reliability.

At any given time, a Leader can only be elected to serve data when a majority of replicas reach a consensus. This mechanism ensures there is only one active primary (the Leader), preventing data corruption and chaos caused by multi-primary conflicts. The transactional consistency and storage durability mechanisms in OceanBase ensure that in the event an OBServer node exits or restarts, the system can be perfectly restored to its exact pre-restart data and state.

Leveraging a distributed election mechanism based on the Paxos protocol, when the serving Leader replica fails, a new Leader is automatically elected from the remaining Follower replicas to take over services, as long as a majority consensus is reached. This process requires no manual intervention.

It fundamentally eliminates the "split-brain" problem and drastically reduces the Recovery Time Objective (RTO). This enables OceanBase to achieve an RPO of 0 (zero data loss) and an RTO of less than 8 seconds, meeting the highest industry standards for availability.

Furthermore, OceanBase supports high-availability and disaster recovery deployments across a single data center, multiple data centers in the same city (e.g., dual-DC or two-locations-three-centers), and multiple cities (e.g., three-locations-five-centers). It also supports the deployment of an arbitration service (witness) to effectively reduce hardware costs.

Beyond the multi-replica high availability of the database nodes themselves, application requests are routed through a proxy service (ODP/obproxy). Combined with comprehensive solutions like backup and recovery and primary/standby database setups, this ensures continuous availability across different components and scenarios.

The result is a database built to serve exactly the kind of organizations this guide has walked through: financial institutions and fintech platforms that cannot compromise on correctness, retailers, e-commerce platforms, gaming studios, and digital-native businesses that face extreme and unpredictable concurrency, telecom operators processing enormous transaction volumes around the clock, and government and public-sector organizations that need resilience without vendor lock-in. Across all of these, the same underlying architecture, verified by independent, industry-standard benchmarks and hardened in production at some of the largest transaction volumes in the world, is what makes OceanBase a credible foundation for mission-critical, distributed workloads at virtually any scale.

Choosing a distributed database is ultimately a decision about which trade-offs a business is no longer willing to accept: capacity ceilings, single points of failure, or the growing cost and rigidity of a proprietary, single-node system. For organizations that need to combine strict correctness with extreme scale and near-continuous availability, a natively distributed architecture is no longer an emerging option; it is the standard that mission-critical systems are increasingly built on. OceanBase's record across independent benchmarks and production environments handling some of the highest transaction volumes in the world reflects what that standard looks like in practice.