Built to Scale: Unifying Transactions, Analytics, and Intelligence with OceanBase

Last week, I had the opportunity to speak at Dine with DevOps, Delhi on “Built to Scale: Unifying Transactions, Analytics, and Intelligence with OceanBase.” What interested me most was not simply database size or benchmark throughput. It was how differently scale appears once we put a real business workflow around it.

A payment authorization, a flash-sale checkout, a diagnostic sample, a subscriber update and a parcel scan look unrelated at the business layer. At the data layer, however, each becomes a sequence of writes, consistency boundaries, hot access paths, failover requirements and increasingly a demand for decisions on data that changed only seconds ago.

That is where database architecture becomes more interesting than a feature checklist.

At a simplified level, OceanBase separates the application's logical view of the database from the physical distribution of data. In OceanBase 4.x, each table partition corresponds to a tablet, while a non-partitioned table also corresponds to one tablet. Tablets are managed within log streams (LS). An LS can have multiple replicas, with one leader and follower replicas; the leader synchronizes and persists logs across replicas through Paxos. ODP can route requests using partition-location information, and, when distributed transaction routing is enabled, DML statements within one transaction can be routed to the OBServer nodes that host the relevant data.

A simplified OceanBase distributed data path

The important point is not that the database is distributed. Many systems are. The design question is which distributed-system responsibilities remain inside the database and which ones leak into application code.

A payment workflow is a good example because the transaction boundary is easy to see. Imagine an authorization that must validate an account, create a payment record, update a balance or limit, write an immutable business event and return a decision.

Payment workflow

If account, payment and ledger data are manually sharded by the application, a transaction that crosses shard boundaries becomes an application architecture problem. With OceanBase, partitioning is managed inside the database rather than exposed as an application-maintained database fleet. In OceanBase 4.x, the WAL of a single log stream can guarantee atomicity for a transaction that modifies multiple tablets within that LS. When a transaction modifies multiple log streams, OceanBase uses an optimized two-phase commit protocol to guarantee atomicity across them.

The second architectural question is the risk path. A fraud or operations query often needs the latest payment state. For operational risk analysis, HTAP can allow analytical access against current operational data rather than forcing every decision through CDC into another system. A separate warehouse may still own historical BI and regulatory analytics; the point is to distinguish those workloads from second-by-second operational decisions.

Commerce creates a different distributed-systems problem: skew. During a campaign, ten million products are not equally hot. A handful of SKUs may receive a disproportionate share of inventory checks and decrements.

Commerce hot-key workflow

Simply saying 'horizontal scale' does not solve a hot partition. The partition key has to match the access pattern, and teams need to understand whether inventory is naturally keyed by SKU, warehouse, merchant or another business dimension. Global indexes, cross-partition access patterns and multi-log-stream transactions must be evaluated rather than hidden behind a node-count estimate.

OceanBase supports automatic load balancing and data redistribution as tenant resources or topology change, subject to the relevant balancing configuration being enabled. Tablets are the smallest data-balancing unit, and the system can transfer tablets between log streams and migrate replicas/resources as part of balancing and scale operations. Schema and partition design still matter: distributed databases reduce application-managed sharding mechanics; they do not remove the need to understand workload locality.

The same commerce platform may also keep variable product attributes in JSON, use full-text search for discovery and vector similarity for semantic retrieval. Those capabilities are useful when they reduce copies of product and inventory context, not because every search workload must be consolidated.

A diagnostics platform illustrates why HTAP is more than 'OLTP + BI.' Consider the lifecycle of a test order.

Diagnostics operational workflow

Every stage changes operational state. The lab team does not want yesterday's turnaround-time view; it wants to know which samples are approaching SLA breach now. Copying the workflow into a separate analytical platform can be justified for enterprise reporting, but it is an unnecessary detour for many operational dashboards.

OceanBase's row, column and hybrid row-column capabilities provide different physical access paths for transactional lookups and analytical scans. Hybrid row-column tables can serve TP and AP queries against the same strongly consistent operational data, with the optimizer choosing the appropriate access path. Where stronger TP/AP resource isolation is needed, OceanBase can also use dedicated columnstore replicas for analytical workloads. Historically, columnstore replica access was primarily associated with weak-consistency analytical reads; OceanBase 4.6 adds strong-consistency read capability to the columnar-replica access path. The required consistency and routing policy should therefore be stated according to the target release and deployment configuration.

Healthcare also demonstrates multimodel requirements. Structured order data can coexist with JSON attributes and searchable report-oriented content. The architecture should keep authorization and current workflow state anchored to the system of record even when richer retrieval is added.

Telecom makes partition locality visible. Subscriber profile, plan, entitlement, session or charging-related state is frequently accessed by subscriber identity. If the dominant operations share the same key, colocating related records can turn many operations into local transactions.

Why partition locality matters

This is where physical data modelling and distributed architecture meet. A poor partition key can create hot spots or turn common operations into distributed transactions. A good one can keep the dominant request path local while still allowing the cluster to scale horizontally.

OceanBase removes the operational burden of maintaining a fleet of application-visible shards, but partition strategy remains a first-class design exercise.

A logistics workflow is both write-heavy and time-sensitive. Every scan, hand-off, hub arrival, departure and delivery attempt changes state. At the same time, a control tower wants to identify backlog, route exceptions and SLA risk.

Logistics state-to-decision path

This workload benefits from keeping transactional state and operational analytics close together. In MySQL mode, OceanBase supports spatial data types and spatial indexes, with documented limitations such as local-only spatial indexes and SRID requirements. These capabilities can complement relational filters for location-aware use cases. The technical value is avoiding a chain where a shipment event must first traverse CDC, transformation and another database before an operations team can see the exception.

SaaS creates a resource-isolation problem rather than only a data-volume problem.

Tenant isolation on shared infrastructure

The extremes are familiar: one physical stack per tenant creates an expensive database fleet, while one completely shared instance risks noisy-neighbor behavior. OceanBase tenants provide isolated data, privileges and resource allocations on shared cluster infrastructure. Resource units define tenant CPU and memory allocations, and OceanBase implements tenant-level resource isolation within the database. This reduces cross-tenant contention risk, while appropriate sizing and workload governance remain necessary. That lets platform teams reason about consolidation separately from resource allocation.

The design discussion then becomes concrete: which tenants need dedicated resource units, which can share pools, what are their peak-to-average ratios, and whether analytical workloads should share or be isolated from transactional capacity.

A production retrieval flow rarely consists of 'send text to a vector database.' Consider a support or commerce assistant:

Hybrid retrieval grounded in operational state

The hard part is not generating an embedding. It is combining semantic relevance with structured predicates and current business state. OceanBase supports relational and JSON data, full-text search, and vector search in supported releases and modes. In OceanBase 4.6, the HYBRID_SEARCH SQL interface can combine full-text search, vector search, and filter conditions in a single SELECT path; scalar and JSON/ARRAY filters are supported subject to the documented HYBRID_SEARCH limitations. This makes it possible to evaluate hybrid retrieval without automatically separating vector representations from operational context.

For some applications a dedicated vector platform will still be the right choice. The architecture question is whether its specialization justifies another synchronization boundary.

These workflows look different, but they expose the same architectural layers:

A workload-first view of the OceanBase architecture

This is why I prefer to discuss OceanBase from the use case inward rather than from the feature list outward. The relevant question for a customer is not whether a database supports Paxos, columnar storage or vectors in isolation. It is which architectural boundary those capabilities allow us to remove, simplify or make more reliable.

A distributed operational database should not become an excuse to force every workload onto one platform. Large historical BI, lake-scale processing, highly specialized search, or independent data-science environments may have very different economics and access patterns.

A useful design review asks: Does the specialized system provide enough benefit to justify another copy of data? What is the freshness requirement? What is the recovery path when synchronization fails? Which system is authoritative? Can the application tolerate different consistency timelines?

When specialization has a clear answer to those questions, use it. When it exists only because 'analytics goes somewhere else' or 'vectors need another database,' it is worth revisiting the architecture.

The point I wanted to make at Dine with DevOps was not that every workload should be collapsed into one engine. It was that scale should be measured in more than transactions per second.

A platform is truly built to scale when a payment spike does not require application-managed resharding, a flash sale can be handled with deliberate partition design and online rebalancing, an operations dashboard does not depend on yesterday's ETL, tenant resource controls reduce noisy-neighbor risk, and a retrieval workflow can stay close to current business state.

That is the architectural direction behind unifying transactions, analytics and intelligence: keep the transactional foundation strong, add new access patterns where they naturally belong, and introduce another system only when the workload earns the additional boundary.

The goal is not fewer boxes on a diagram. The goal is fewer boxes that exist only because the architecture could not scale with the business.

The architectures and industry use cases discussed are illustrative; OceanBase capabilities and applicability may vary by product version, compatibility mode, deployment topology, configuration and workload requirements, and should be evaluated against the applicable product documentation.