Why HTAP Databases Matter: Inside Oracle HeatWave, Google AlloyDB, TiDB, and OceanBase

Many database products now claim to support HTAP (Hybrid Transactional/Analytical Processing). While some have invested heavily in real HTAP capabilities, others merely use the label for marketing. Google entered the field in May 2023 with AlloyDB, its first HTAP cloud‑native database, and Snowflake followed with Unistore, though details on the latter remain scarce.

Oracle MySQL HeatWave

Oracle’s HeatWave is a plugin for the InnoDB engine that creates an in‑memory columnar replica of tables on a separate HeatWave cluster (up to 64 nodes). When the SQL engine detects an OLAP or ML workload, the query is offloaded to HeatWave, achieving OLTP/OLAP load separation and high‑performance analytics (memory + columnar). The columnar data is persisted to OCI storage to reduce restart overhead.

Oracle promotes HeatWave as up to 1,400× faster than Amazon Aurora with half the cost, though the solution requires expensive high‑performance hardware and is only available on Oracle Cloud.

Potential bottlenecks are mitigated because the MySQL instance pushes computation to the HeatWave cluster, preventing the primary instance from becoming a choke point.

Google AlloyDB for PostgreSQL

AlloyDB adopts a centralized architecture similar to Aurora: a primary node with a read‑pool and shared log‑based storage. It adds a columnar in‑memory engine via the PostgreSQL extension, activated with SELECT google_columnar_engine_add('xxx');. This mirrors Oracle’s in‑memory approach, allowing manual creation of columnar replicas for AP workloads.

AlloyDB also optimizes WAL replay on read‑only nodes by replaying only cached data, reducing I/O. Google claims AlloyDB is four times faster than native PostgreSQL; independent tests report performance gains ranging from several‑fold to tens of times for large analytical queries.

Domestic HTAP Solutions

Chinese vendors often use distributed architectures. Polardb‑PG/Polardb‑O mimic Aurora’s read/write separation, while many other products are fully distributed.

TiDB originally relied on TiSpark for analytical queries. Starting with TiDB 4.0, TiFlash—a columnar storage engine with ClickHouse‑style compute—was introduced. Writes remain row‑store (OLTP‑friendly); during merges, a TiFlash replica is generated for AP workloads. TiDB 5.0 further refines push‑down operators, enabling finer‑grained offload similar to HeatWave.

TiFlash incurs extra storage and compute costs, and the replication process can introduce latency spikes that affect TP performance, a focus for future optimization.

OceanBase uses a unified storage layer with micro‑block hybrid row/column compression, reminiscent of Oracle Exadata’s SmartScan. AP queries can be directed to read‑only replicas via HINTs, and OBPROXY can be tuned (e.g., adding parameters) to achieve automatic workload isolation without explicit hints. A resource manager caps AP resource usage to protect TP stability.

Takeaways

HTAP implementations vary widely in architecture, cost, and performance. Selecting a suitable HTAP database requires aligning the product’s technical trade‑offs with specific business workloads. Deploying HTAP systems also introduces operational complexity—developers must understand offload mechanisms, tuning parameters, and potential impacts on TP performance.