Start Small, Scale Big: Inside OceanBase's Distributed Architecture

For many enterprises, database scaling is not just a performance problem. It is an architectural continuity problem.

OceanBase addresses this with an integrated standalone-distributed architecture. Businesses can start with a small deployment that behaves much like a standalone database, then scale out to a distributed system as they grow. This helps reduce repeated migrations, sharding complexity, and the operational burden of maintaining multiple database systems.

Database Scaling Often Arrives Earlier Than Expected

Many companies start with MySQL. It is simple, open source, mature, and familiar to most engineering teams. For early-stage businesses, a standalone MySQL database is often enough.

As the business grows, database pressure builds quickly. Order volume increases, tables grow, and queries slow down. Teams often add read-write splitting, caching, and eventually sharding. Each step solves an immediate problem, but also adds application changes, migration risk, and operational complexity.

That is why many CTOs eventually ask: Why should every new stage of business growth require another painful database rebuild?

The challenge is not only how to scale, but how to scale without repeatedly changing the database architecture.

Existing Scaling Paths Still Involve Trade-offs

Traditional database scaling usually follows one of two paths:

• Open-source path: MySQL standalone → MySQL sharding → NewSQL distributed database
• Commercial path: Oracle standalone → Oracle RAC → NewSQL distributed database

Both paths can solve problems at certain stages, but they also introduce long-term challenges.

Standalone databases and shared-storage clusters have scaling limits. Hardware upgrades can relieve pressure, but they do not truly provide linear scale-out for massive data volumes and high concurrency.

Sharding breaks through the capacity limit of a single machine, but it pushes complexity to applications and operations. Cross-shard queries, distributed transactions, data migration, scaling, and failure handling all become more difficult.

Cloud-native databases improve elasticity and high availability. However, in many primary-replica architectures, write throughput may still be limited by the primary node.

NewSQL databases provide horizontal scalability, but they may also involve trade-offs in small-scale cost, standalone performance, operational complexity, and ecosystem maturity.

Enterprises do not need another architectural bet. They need a database path that can handle current workloads without limiting future scale-out.

OceanBase's Approach: One Architecture for Standalone and Distributed Deployment

OceanBase's answer is an integrated standalone-distributed approach — one architecture that supports both standalone and distributed deployment. This capability was introduced in OceanBase 4.0 and has since become the foundation of the product's scaling model.

The idea is simple: Start small, scale big.

In the early stage, OceanBase can run as a small standalone deployment, supporting business workloads at a lower cost while keeping performance and operations close to those of a traditional standalone database.

As the business grows, the same OceanBase system can scale out into a distributed cluster to support larger data volumes, higher concurrency, and stronger high availability.

The key point is that the deployment model can change without requiring a different database architecture. Teams can start small and scale out as needed within the same system.

One of the core technologies behind this capability is dynamic log stream.

Dynamic Log Stream: Combining Standalone Performance with Distributed Capability

A key part of this architecture is the dynamic log stream mechanism.

In many distributed database designs, data is divided into shards. As the number of shards increases, the system may need to manage more log streams. This can make distributed overhead grow with the number of shards, even when the actual deployment size remains small.

The scaling path may look like this:

More data
  → More shards
  → More log streams
  → Higher distributed overhead

OceanBase takes a different approach: log streams scale mainly with the number of nodes, rather than simply with the number of shards. As a result, distributed overhead is more closely related to deployment scale, instead of growing directly with the number of data shards.

In a single-tenant scenario, this can be illustrated as follows:

Note: The table above is based on a single-tenant scenario. In multi-tenant scenarios, the total number of log streams is also affected by the number of tenants and resource distribution.

This design brings three key benefits:

1. Flexible partition placement: Data partitions can be dynamically bound to different log streams, supporting flexible migration.
2. Lightweight standalone deployment: In standalone deployment, there is only one log stream, and the transaction processing path is similar to that of a classic standalone database.
3. More controllable scale-out: When the system scales horizontally, log streams increase mainly with the number of nodes, keeping distributed overhead more controllable.

This is what allows OceanBase to stay lightweight in small deployments while preserving a path to large-scale distributed expansion.

Optimizing for the Common Path

OceanBase is also designed around a practical observation: in many business systems, most database operations are local to a single user, account, order, or tenant. Only a smaller portion requires cross-node coordination, such as cross-account transactions or global analytics.

Based on this observation, OceanBase optimizes for the common path:

• For common single-node operations, OceanBase minimizes unnecessary distributed overhead so that performance remains close to standalone databases.
• For cross-node operations, OceanBase uses mechanisms such as two-phase commit, parallel execution, and asynchronous processing to improve execution efficiency.

This helps OceanBase keep common operations efficient while still supporting distributed execution when needed.

Business Value and Best-Fit Scenarios

For enterprises, OceanBase's integrated standalone-distributed architecture delivers value beyond raw performance — it lowers long-term architecture cost and reduces evolution risk.

In practice, this means:

• Lower total cost of ownership through compression, automatic load balancing, automatic failover, and multi-tenant isolation.
• A smoother scale-out path from small deployments to large distributed clusters.
• High availability for critical workloads, supported by Paxos-based three-replica strong synchronization, RPO = 0, and fast failover.
• Fewer systems to maintain by supporting OLTP, real-time OLAP, Key-Value, JSON, and GIS use cases in one database.

This makes OceanBase especially relevant for startups, fast-growing companies, large enterprises, and financial institutions that need to scale without repeated migrations, manual sharding, or deep cloud lock-in.

Adoption Path: Start with a Small Validation

Enterprises do not need to start with a large distributed deployment. A gradual adoption path is often more practical:

1. Standalone validation: Start with a non-critical workload and test SQL compatibility, performance, and operations.
2. Small distributed deployment: Deploy a three-node cluster and validate high availability, failover, backup and recovery, and monitoring.
3. Scale on demand: Expand gradually as workloads grow and promote best practices across more systems.

This lets teams validate, deploy, and scale within the same database system.

Database selection should not force enterprises to rebuild their architecture at every stage. It should provide a foundation that evolves with the business.

That is the goal of OceanBase's standalone-distributed architecture:

Start small, scale big — without rebuilding the database architecture at every stage.

Further Reading

• OceanBase log streams
• OceanBase Database architecture
• OceanBase Database Documentation