In 2014, Gartner coined a term for one of the most seductive ideas in data infrastructure: HTAP, Hybrid Transactional/Analytical Processing. One database that runs your application and your analytics. No nightly ETL jobs, no stale dashboards, no second copy of your data. You would query live transactions directly and make decisions on what is happening right now, not on what happened yesterday.
It is worth understanding why that idea was so compelling, why it mostly did not happen the way Gartner sketched it, and why its core promise is nevertheless being fulfilled today, just through a different architecture. That architecture is the one Dataddo lives in, which is why we care.
The promise
Traditional data stacks split into two worlds. OLTP databases (Postgres, MySQL, SQL Server) handle transactions: many small reads and writes, row by row, with strict consistency. OLAP systems (BigQuery, Snowflake, ClickHouse) handle analytics: huge scans and aggregations across millions of rows, best served by columnar storage. Between them sits a pipeline, and historically that pipeline ran in batches. The analytical copy of your business was hours or a day behind the operational one.
HTAP said: collapse the two worlds into one engine and the lag disappears. SAP HANA, TiDB, SingleStore, and later Snowflake's Unistore all took a swing at it, each with a different internal design (typically some combination of a row store and a columnar store kept in sync inside the engine).
Why one engine turned out to be the hard way
The physics of the two workloads pull in opposite directions. Transactions want row-oriented storage and predictable low latency. Analytics wants columnar storage and is happy to saturate CPU and I/O for seconds at a time. Put both on one box and the analytical scan steals resources from the checkout flow. Keep both storage formats inside one engine and every write happens twice. Isolate the workloads onto separate replicas and you have quietly rebuilt the two-system architecture you were trying to escape, just with one vendor's logo on it.
None of the single-engine HTAP databases became the default. By 2025 the market was moving visibly the other way: Snowflake acquired Crunchy Data and Databricks acquired Neon, both analytics platforms buying dedicated Postgres companies rather than stretching their engines toward OLTP. AWS pairs Aurora with Redshift through zero-ETL integration rather than merging them. One widely shared engineering essay from 2025 put it bluntly in its title: "HTAP is Dead." (Those market events are reported in ClickHouse's engineering write-up, linked below, which we cite as a secondary source.)
What actually changed: the pipeline got fast
Here is the part that matters. HTAP the product category stalled, but HTAP the capability — analytics on data that is seconds old — is now routine. What changed was not the database engine. It was the pipeline between engines.
In 2014, moving data from an operational database to an analytical one meant batch ETL with hours of latency, which is exactly why "eliminate the pipeline" sounded like the only fix. Since then, change data capture (CDC) matured from an exotic technique into a commodity: instead of re-exporting tables on a schedule, you stream the database's own change log continuously, and the analytical copy trails the operational one by seconds. The industry name for the result is "composed" or "best-of-breed" HTAP: a dedicated transactional engine, a dedicated analytical engine, and a fast replication layer in between. Each component does the thing it is physically good at.
This is the architecture the big platforms are now converging on from both sides. It won not because it is fashionable but because it dissolves the original dilemma: no resource contention, each engine scales independently, and the second write moves off the commit path instead of competing with it.
Where Dataddo fits
Dataddo is not an HTAP database, and this post is not going to pretend otherwise. Dataddo is the layer that composed HTAP depends on: the managed pipeline between your operational systems and your analytical ones.
Concretely, that means CDC-based replication from operational databases, sync intervals down to every minute across 400+ connectors, and one platform covering the whole path (extraction, transformation, loading, and reverse flows back into business tools), so you are not gluing together a capture tool, a queue, and a loader yourself. For European companies there is a second-order point: in a composed architecture the pipeline is a system of its own, and it processes your data. Dataddo runs with EU data residency and is ISO 27001 and SOC 2 Type II certified, which keeps the "third box" in your architecture inside the same compliance boundary as the two databases it connects.
Should you use an HTAP database or a composed stack?
An honest checklist, since the single-engine products do have a home:
- Your analytics must see a write within the same second, inside one transaction boundary (fraud scoring at payment time, in-game leaderboards): a purpose-built HTAP or translytical engine is worth evaluating.
- Your analytics needs to be seconds-to-a-minute fresh (live dashboards, operational reporting, feeding an AI agent current business state): a composed stack with CDC covers it, and you keep best-in-class engines on both sides.
- You have many sources, not one database (SaaS tools, ad platforms, several databases): the single-engine model does not even apply. The pipeline layer is your architecture, so its speed and reliability are what determine how "real-time" your analytics actually is.
Most companies are in the second and third buckets. That is why we think the interesting frontier is not inside any one engine. It is the connective tissue, and making that tissue fast is precisely the problem Dataddo works on.
Further reading
- Gartner's original framing and the term's history: Wikipedia: Hybrid transactional/analytical processing
- The composed-architecture argument and 2024–2026 market timeline: ClickHouse Engineering: Unifying OLTP and OLAP
- Engine internals of the single-box attempts: PingCAP: Real-World HTAP — TiDB and SingleStore architectures and the academic HTAP Databases: A Survey (arXiv)
Comments