HTAP on OceanBase lets one cluster serve POS-style OLTP and same-day analytical aggregates. Use resource groups to cap analytical CPU during peak hours, and column store or read paths where your edition supports them for scan-heavy queries.

HTAP means the same database serves transactional writes and analytical queries. Retail inventory is a common pattern: POS updates need low latency, while merchandising wants same-day rollups without an overnight ETL job.

OceanBase can keep both paths on one cluster using row storage for writes and, when enabled, column-store projections for scans.

Example workload shape

Use numbers from your own traffic, not generic examples. A mid-size chain might target:

  • OLTP: continuous inventory_levels updates with a p99 latency goal defined by the business.
  • OLAP: hourly SUM(quantity) by SKU and store over a recent time window.

Validate latency and freshness in staging before promising same-day analytics in production.

Architecture

Route OLTP through primary replicas. Enable column store projection on hot analytical tables when supported, or use read paths with documented freshness limits.

Query pattern

SELECT sku, store_id, SUM(qty) AS sold
FROM order_lines
WHERE sold_at >= NOW() - INTERVAL 24 HOUR
GROUP BY sku, store_id;

Add a composite index on (sold_at, store_id, sku) for row-store fallback when column store is disabled.

Keeping OLAP from starving OLTP

Place analytical sessions in a resource group and cap CPU share during business hours. Move heavy scans off peak when the business allows.

Sources and further reading