The Great Convergence of Transactional and Analytical Data Platforms

The emerging transactional and analytical data platform convergence does not result in one universal database, but in fresher operational data through governed data planes, workload-specific engines, and replication, federation, or shared storage.

The OLTP/OLAP convergence story has moved from theoretical to genuinely architectural in the past 12-18 months, and the strategies diverge in a telling way: cloud platform vendors are converging at the storage layer using open table formats, while database vendors are converging at the engine layer inside a single product. OLTP and OLAP still have different performance envelopes: OLTP optimizes low-latency reads/writes, concurrency, and transactional integrity; OLAP optimizes large scans, aggregations, joins, historical analysis, and cost-efficient compute at scale.

The real trend is this: vendors are trying to collapse the operational-to-analytical distance by making data available for analytics, AI, and applications with less ETL, lower latency, stronger governance, and fewer duplicated semantic models. This is necessary for faster activation of operational data and to simplify AI agents’ access to analytical data and operational data stores – especially, for the agents that are supposed to be part of business operations and are required to act upon new data in real time.

The convergence is happening through four main patterns:

1. Single-engine/dual-format HTAP: One database supports transactions and analytics, often with row plus column representations.
2. Operational engine embedded in an analytics platform: OLAP/lakehouse vendors add Postgres-like or row-store capabilities.
3. Near-real-time mirroring into a lake/warehouse: Operational data remains in OLTP storage but is automatically materialized into analytical storage.
4. Zero-copy/federation/data-sharing layers: Data stays where it is, while another platform queries, governs, activates, or semantically models it.

No vendor has eliminated the trade-off. The best platforms are making the trade-off explicit and manageable.

Microsoft. Fabric’s strategy has been “shared storage, specialized compute”: OneLake holds data in Delta/Parquet (with Iceberg interoperability), and SQL Database in Fabric, the Warehouse, Lakehouse, and Eventhouse each query it with engines tuned to their workload. In March 2026, Microsoft pushed this further, explicitly framing the goal as unifying transactional, operational, and analytical data under one architecture, with Database Hub and Fabric IQ as connective tissue and SQL Server, Cosmos DB, and the new Fabric Databases folded into the same narrative. SQL Database in Fabric auto-mirrors every transactional write into OneLake as Delta tables, exposed instantly through a read-only SQL analytics endpoint – so the OLTP store and the OLAP-queryable copy are kept in sync without a customer-built pipeline, even though they remain two physical representations.

Oracle has taken the opposite path: one engine, one storage format, many data models. Oracle Database 23ai/26ai is marketed as a “converged database” that natively handles relational, JSON, graph, spatial, and vector data plus in-memory columnar analytics (Database In-Memory) on top of the same row-store, rather than syncing a separate OLAP copy. This is architecturally the closest thing to classic HTAP – single engine, dual access paths – and it leans heavily on Exadata hardware to make the analytical path fast enough not to contend with transactional throughput.

Salesforce isn’t trying to converge OLTP and OLAP inside one engine at all; it’s converging via the open table format at the edge of its platform. Data Cloud’s internal lakehouse is built on Iceberg, and “Zero Copy” lets external Snowflake/Databricks/BigQuery/Redshift data be queried in place or read directly off Iceberg/Delta storage, bypassing the source’s compute, so CRM transactional data and external analytical data sit in the same governed layer without ETL enabling use cases beyond core CX, i.e. operational, planning, financial data. This is consolidation at the metadata/catalog level rather than the storage-engine level.

MongoDB’s convergence runs through document-model flexibility plus added analytical and AI surface area (Atlas Search, vector search, the Voyage AI-powered reranking) layered on the same operational cluster – closer to “one platform, many query modes” than true HTAP, since heavy OLAP-style aggregation still competes for the same cluster resources unless you offload to Atlas Data Federation or a dedicated analytics node.

Snowflake and Databricks have converged on nearly identical playbooks: Databricks bought Neon (Postgres) for roughly $1B in May 2025, and Snowflake countered by acquiring Crunchy Data for about $250M weeks later – both moves aimed squarely at owning a transactional Postgres layer next to their analytical engines. Snowflake’s path runs through Unistore/Hybrid Tables (a native transactional table type inside Snowflake) plus the newer Snowflake Postgres service and the open-sourced pg_lake extension, which lets Postgres write directly to Iceberg tables with full transactional semantics – so an operational Postgres database and the analytical lakehouse can, in principle, share one copy of data. Databricks pushed a step further: at its June 2026 Data + AI Summit it announced “LTAP” (Lake Transactional/Analytical Processing), explicitly positioned as the successor to both classic HTAP and zero-ETL. The pitch is that Lakebase (its serverless Postgres) now writes data directly into Delta/Iceberg format rather than Postgres-native format, so the transactional and analytical engines read the literal same files via Unity Catalog – no CDC pipeline at all. Worth flagging: this is vendor’s own framing of a feature announced only weeks ago, independent reviews of how well it performs at scale aren’t really available yet, and Databricks’ own co-founder has been explicit that prior approaches (HTAP, zero-ETL) underdelivered, which is useful context for how much skepticism to apply to the new claims too.

EnterpriseDB is running a similar storage-layer convergence play but staying Postgres-centric rather than building a new transactional engine. Its 2026 EDB Postgres AI release adds “Converged Analytics,” which publishes operational Postgres data to an Iceberg catalog so EDB’s own ClickHouse-based real-time layer and its WarehousePG (Greenplum-lineage) historical layer can both query it without a second copy – the same “Postgres writes, Iceberg catalog serves everything else” idea Snowflake is pursuing with pg_lake, which is unsurprising given that Crunchy Data’s lineage runs through both companies’ Postgres extension work.

SAP HANA sits in the HTAP column for operational SAP data, while SAP Business Data Cloud + Dremio sits in the open-format column for everything else. That dual positioning is the architectural bet behind the Dremio acquisition. SAP Business Data Cloud will become an Apache Iceberg-native enterprise lakehouse, with Dremio’s catalog layer – built on Apache Polaris and the open Iceberg REST Catalog API – serving as the discovery and semantic layer across both SAP and non-SAP sources. This is the same federation-over-open-format pattern as Salesforce’s Zero Copy and Snowflake’s Horizon Catalog: SAP isn’t trying to absorb non-SAP OLTP/OLAP workloads into HANA; it’s trying to own the metadata and access layer that sits above everyone’s data, wherever it lives.

Logical convergence vs. physical convergence

A lot of vendor messaging sounds similar, but the underlying architecture differs materially. Therefore, customers need to carefully assess their specific use-case scenarios and map to the idiosyncrasies of how each vendor is operationalizing that.

Physical convergence means one engine or tightly integrated engine family handles both workloads. Oracle Database In-Memory is the canonical example, with row and column formats inside the same database architecture. Snowflake Hybrid Tables and some SQL Server columnstore scenarios also move in this direction, though with different maturity and workload assumptions.

Replica-based convergence means the OLTP system remains distinct, but changes are automatically propagated into an analytical representation. Microsoft SQL database in Fabric and EnterpriseDB’s Postgres Analytics Accelerator are good examples. This is often the most practical enterprise pattern because it protects OLTP performance while reducing ETL burden.

Federated or zero-copy convergence means the data is not necessarily moved; instead, another platform queries, shares, semantically models, or activates it. Salesforce Data 360 and Snowflake/Databricks ecosystem integrations fit here. This reduces duplication but introduces dependency on query pushdown, network paths, permissions, source-system load, and semantic consistency.

Platform-control convergence means the vendor wants one governance, catalog, security, lineage, and developer experience across multiple physical engines. Microsoft Fabric, Databricks Unity Catalog/Lakebase, Snowflake Postgres/Hybrid Tables, and EDB Postgres AI are all moving in this direction.

Buyer’s checklist

For each vendor, the critical questions are:

1. Is there actually one copy of data, or is the platform creating a managed replica?
2. What consistency model applies across OLTP and OLAP views?
3. Can analytical workloads starve transactional workloads?
4. What happens during failover, restore, region outage, or replication lag?
5. Are governance policies enforced once, or reimplemented across engines?
6. Which features are unavailable in the converged mode compared with the vendor’s mature OLTP or OLAP product?
7. Does the architecture reduce complexity, or merely hide it behind proprietary control planes (i.e. would you be getting a new veneer or fundamental renovation)?

Our Take

Cross-vendor pattern, and a genuine debate inside the industry. A useful piece of skepticism worth flagging: There’s a live disagreement about whether single-engine HTAP (Oracle’s bet) or storage-layer convergence via open formats (everyone else’s bet) actually wins. A Mooncake Labs co-founder (now at Databricks) published “HTAP is Dead” in 2025, arguing resource contention and hardware constraints make composed best-of-breed systems more durable than consolidated engines – which is a notable internal tension given Databricks then turned around and announced LTAP as its own unification claim a year later. AWS’ path (Aurora zero-ETL to Redshift/SageMaker Lakehouse) and ClickHouse Cloud’s newer managed-Postgres-plus-NVMe approach are both still firmly in the “composed, CDC-bridged” camp rather than single-copy convergence, suggesting the market hasn’t actually settled this question yet, despite the marketing convergence around Iceberg as the shared format.

The future is not “OLTP and OLAP become one database.” The more accurate conclusion is: Enterprises are moving from batch-separated systems of record and systems of insight toward governed, low-latency data platforms where operational, analytical, AI, and application-serving workloads are coordinated inside one control plane.

The winners will not necessarily be the vendors claiming the purest “single copy” story. The winners will be the ones that deliver the best combination of freshness, workload isolation, governance, cost control, developer experience, and operational reliability.

Want to Know More?

• SAP Acquires Dremio, Reltio, and Prior Labs to Create an Agentic AI Platform and Research Center for Structured Data
• Salesforce Data 360 and Snowflake