Why After Five Years HTAP Still Can’t Replace Separate OLTP and OLAP?

At a recent tech summit the speaker praised HTAP (Hybrid Transactional/Analytical Processing) as the future of databases, but the author and friends rolled their eyes, noting that most companies still run MySQL for transactions and ClickHouse for analytics.

What are OLTP and OLAP?

OLTP (Online Transaction Processing) handles high‑concurrency, low‑latency operations such as e‑commerce orders or account updates. Typical systems: MySQL, PostgreSQL, Oracle.

OLAP (Online Analytical Processing) supports complex, large‑scale queries for reporting and data analysis. Typical systems: ClickHouse, Greenplum, Snowflake.

Traditional architectures keep them separate, moving data via ETL.

HTAP’s Promise

HTAP aims to combine both workloads in a single database using a dual‑engine design (row store for OLTP, column store for OLAP) with real‑time synchronization.

Three Major Obstacles

1. Performance Trade‑offs

In practice, heavy OLAP queries steal CPU, memory, and I/O from OLTP. A fintech case study showed that when a real‑time report ran, transaction latency spiked, forcing a rollback to the traditional MySQL + ClickHouse stack.

2. Data Consistency

Row‑to‑column synchronization can take seconds or longer, making analytical results stale. For e‑commerce flash sales, a 10‑second lag means thousands of missed orders.

3. Operational Complexity

Running a HTAP system requires expertise in both transaction tuning and analytical query optimization, a skill set that is scarce. Teams spent weeks debugging performance bugs that only appeared under mixed workloads.

Migration Cost

Moving a mature core system from MySQL/Oracle to a HTAP platform involves code changes, SQL rewrites, performance re‑testing, data migration, and staff training—often with unclear ROI.

When HTAP Makes Sense

New greenfield projects without legacy baggage.

Cloud‑native companies using managed HTAP services (e.g., PolarDB, TDSQL).

Scenarios demanding sub‑second analytics, such as financial risk monitoring or real‑time logistics.

These cases represent a small fraction of overall analytics workloads.

Practical Recommendations

For most small‑to‑medium businesses, stick with proven open‑source stacks: MySQL/PostgreSQL for OLTP, ClickHouse/Doris for OLAP, and use CDC tools like FineDataLink for near‑real‑time data sync.

Large enterprises can adopt a hybrid approach: keep core transactional systems (e.g., Oracle) unchanged, use Flink + ClickHouse for real‑time streams, and build a data warehouse (Hive, Snowflake) for batch analytics.

BI tools such as FineBI can unify multiple data sources, giving business users self‑service analytics without exposing underlying database complexity.

Getting Started with HTAP

Pilot HTAP on non‑critical workloads (user behavior analysis, operational dashboards) before considering core transaction migration.

Never replace a stable OLTP system with HTAP without a clear performance and cost justification.

Future Outlook

HTAP will occupy a niche, but the broader trend is toward platform‑centric, service‑oriented data architectures where multiple specialized databases coexist and are glued together by integration tools.

Ultimately, stability, maturity, and controllable latency outweigh the allure of a single “all‑in‑one” database.