Beyond HTAP: What a Unified Data Platform Actually Requires

Most enterprise data architectures grew organically — MySQL or Oracle for transactions, a columnar warehouse for analytics, Elasticsearch for text, a vector database for embeddings, and Kafka or Fivetran stitching it all together. This pattern emerged because databases specialized: row stores for writes, column stores for scans, purpose-built engines for search and vectors.

That pattern is breaking. Not because of ambition or architectural idealism, but because of latency and cost. When your fraud detection pipeline needs a customer's last five transactions (OLTP), six months of behavioral patterns (OLAP), and a vector similarity score against known fraud signatures (AI) — all within 200ms — a system that fans out across four different engines stops being an architecture and becomes a liability.

The question isn't whether unified platforms are desirable. It's whether they're architecturally possible without compromising on any of the workloads they absorb.

One Platform, Three Workloads

At a high level, OceanBase 4.4.2 LTS provides:

• A single storage engine that handles row-store writes for OLTP, column-store scans for OLAP, and vector indexes for similarity search — on the same data, with no ETL
• Vectorized query execution with SIMD acceleration that delivers TPC-H and TPC-DS performance without a separate analytical engine
• Native multi-model support — JSON, full-text search (BM25), and vector search (IVF_FLAT, IVF_PQ) — queryable in a single SQL statement alongside relational data
• An intelligent optimizer that automatically routes queries to row stores, column stores, or hybrid paths based on cost estimates, not static configuration

This isn't a database with an analytical bolt-on or a vector extension. It's a platform designed from the storage layer up to handle mixed workloads without treating them as separate problems.

Why AI Made Fragmentation Unsustainable

Three things changed that make the unified approach urgent.

First, AI workloads moved from experimental to production. Teams that spent 2024 building prototypes are now deploying them, and the gap between "works in a notebook" and "works on live data" turns out to be a database problem. Vector search on stale exports is manageable for a demo. For a production RAG pipeline that needs current transactions, it's a non-starter.

Second, the cost of fragmentation compounds at scale. Every additional engine means another team to staff, another replication pipeline to monitor, another failure mode to on-call. The real cost isn't licensing — it's the engineering hours burned on integration. A team running three databases doesn't spend 3× the operational effort. They spend 5× to 10×, because each additional system interacts with every other system. The simplicity argument for consolidation is also a reliability argument: fewer moving parts means fewer failure modes.

Third, latency budgets are shrinking. Real-time personalization, fraud detection, and operational AI don't tolerate the seconds of delay that cross-system data movement introduces. When the use case demands a unified view within query latency, architectural separation becomes the bottleneck.

The unified engine approach makes a specific architectural bet: that a single LSM-Tree-based store can serve row-oriented writes and column-oriented scans efficiently enough that the simplicity gain outweighs the per-workload optimization ceiling of specialized engines. Whether that bet pays off depends on how the storage engine is designed.

How One LSM-Tree Serves Three Workloads

One Tree, Two Layouts

The core idea is deceptively simple. OceanBase uses a single LSM-Tree for all data, but it maintains two physical layouts: baseline data is stored in columnar format, and incremental (recently written) data stays in row format. A background compaction process periodically merges incremental rows into the columnar baseline.

This means a row just inserted is available immediately for both transactional queries (via the row-store path) and analytical scans (via the columnar baseline, with the incremental delta merged in at query time). There is no replication lag between a "TP store" and an "AP store" — because there is only one store, with two representations of the same data.

We chose LSM-Tree over B-Tree for a specific reason: the incremental-row / baseline-column split maps naturally onto LSM-Tree's level structure. The higher levels (recent data) favor row layout for fast writes. The lower levels (stable data) favor column layout for compression and scan throughput.

Vectorized Execution and Query Routing

Columnar storage without a vectorized execution engine is like an index without a query planner — the data is there, but you can't access it efficiently. OceanBase's execution engine processes data in batches, leveraging SIMD instructions for operations like hash joins, aggregations, and filter predicates. On TPC-H 100G, vectorized execution delivers a 40× improvement over the row-oriented engine. On TPC-DS 100G, it's 26×.

The optimizer decides per-query whether to use row-store indexes, columnar scans, or both. It's cost-based, not rule-based — the decision depends on selectivity estimates, available indexes, and data distribution statistics. You can override with hints (USE_COLUMN_TABLE), but for most workloads, the optimizer gets it right without intervention.

Adaptive parallelism (Auto DOP) adjusts the degree of parallelism dynamically based on data volume at execution time. A PX adaptive task-splitting mechanism identifies long-tail tasks during distributed queries and rebalances them, preventing a single slow partition from dragging down the entire query.

Multi-Model and AI-Native Capabilities

This is where the architecture extends beyond traditional HTAP. Vector search (IVF_FLAT, IVF_PQ indexes) and full-text search (BM25) are first-class index types, not extensions. A single SQL query can join a relational table with a vector similarity search and a full-text match:

SELECT title, content
FROM documents
WHERE category = 'technical'
  AND MATCH(content) AGAINST('distributed consensus')
  AND vector_distance(embedding, query_embedding) < 0.3
ORDER BY vector_distance(embedding, query_embedding)
LIMIT 10;

No separate vector database. No separate search index. One query, one transaction, one consistency model.

Note: The SQL above illustrates the query pattern. For exact syntax and supported distance functions, see the OceanBase vector search documentation.

We also support Java and Python UDFs for custom logic, Apache Iceberg for querying external data lakes without ingestion, and materialized views with automatic incremental refresh — including nested view cascading. These aren't architectural novelties; they're the capabilities that make a unified platform actually usable in production, as opposed to theoretically elegant.

Proof Points: Hot-Pot Chains, Bank Batches, and EV Dealerships

The architecture described above is running in production today. Three deployments illustrate the range:

Haidilao — the global hot-pot chain with 1,300+ stores and 415 million annual customers — migrated their inventory and membership systems to OceanBase. Their previous architecture mixed DRDS, PolarDB, and ADB, requiring separate pipelines and creating consistency gaps. On OceanBase, HTAP queries power real-time menu recommendations on in-store tablets, combining historical order patterns with current POS data in a single query. Storage compression reached 70–90%, and total database TCO dropped 50%.

Guilin Bank — a regional Chinese bank with $500B+ in assets — replaced Oracle for their CRM and risk management (impairment calculation) systems. These workloads are PL/SQL-heavy with complex multi-table joins and large batch processing. Columnar storage plus Auto DOP cut impairment batch runs from 170 minutes to 75 minutes — a 2.2× improvement. The 10:1 compression ratio reduced 3TB of data to 300GB per replica.

Leapmotor — an EV manufacturer with 1,000+ dealerships — consolidated a sharded MySQL + Elasticsearch setup. Query latency on multi-table joins dropped from seconds to sub-second; CPU utilization fell from 70% to 15% as the optimizer eliminated redundant scans. The MySQL-compatible wire protocol meant zero application changes.

Three Questions Before You Consolidate

If you're evaluating whether a unified platform can replace a fragmented stack, three questions matter more than feature lists:

What's the consistency model across workloads? In dual-engine HTAP architectures, the analytical replica is typically async — queries can see stale data. OceanBase's single-store design means analytical queries and transactional queries read from the same data, with the same consistency guarantees. If your use case tolerates eventual consistency for analytics, this doesn't matter. If it doesn't, it's the difference between the platform working and requiring application-level reconciliation logic.

What happens under mixed load? A system that handles TP, AP, and vector queries individually isn't the same as a system that handles all three simultaneously. OceanBase's four-level isolation — tenant, task, user, and TP/AP replica isolation — ensures that a runaway analytical query doesn't starve transactional workloads. Resource Manager lets you set CPU and memory caps per workload class.

What's the operational surface area? Every additional engine in the stack adds a backup strategy, an upgrade path, a monitoring dashboard, and an on-call rotation. The TCO argument for consolidation isn't primarily about license cost — it's about the engineering hours spent maintaining integration between systems. Haidilao's 50% TCO reduction didn't come from cheaper database licensing. It came from eliminating the pipelines and operational overhead of a three-database architecture.

OceanBase 4.4.2 LTS is available now. The architecture described here reflects the production release — nothing in this post describes roadmap or beta features.For detailed setup, see the OceanBase 4.4.2 documentation.