HTAP means the same database serves transactional writes and analytical queries. A retail inventory system is a common example: 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 these. A mid-size chain might look like:

  • OLTP: continuous inventory_levels updates with a p99 latency target under 25ms.
  • OLAP: hourly SUM(quantity) by SKU and store over roughly 48 hours of line items.

Architecture

Route OLTP through primary replicas. Enable column store projection on order_lines for analytical scans, or use a read-only replica tenant with relaxed freshness (for example 30s).

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

Put analytical sessions in a resource group and cap their CPU share during business hours (many teams start around 30%). Move heavy scans off peak when the business allows it.