For years, transactions and analytics lived separately. That split worked until analytics became part of the workflow. Now platforms are bringing them back together.
For years, the data world ran on a clear separation of duties.
Transactions lived in one place: the operational database. That’s where your application wrote anything that needed to be fast, correct, and durable (e.g. orders, payments, logins, claims, trades). Analytics lived somewhere else: in a warehouse, a reporting database, or a data lake where you could scan big datasets, aggregate, and ask “what happened?”
It was a sensible split between transactional and analytical data: a proper separation of concerns.
And then, over the last decade, it stopped being enough.
There is an undeniable trend: analytics has moved closer to the moment of action. Dashboards became operational. Models started making decisions. Operational workflows began expecting “live” analytical context while the user is still clicking, while the transaction is still pending, while the risk is still rising.
That shift is why we’re seeing a (re)emergence of platforms that unify transactional and analytical worlds.
OLTP systems are built for lots of small operations: insert one row, update one row, fetch by key, repeat. They are predictably fast, highly concurrent, and strict about correctness. OLAP systems are built for fewer, heavier questions: scan a lot of data, group, aggregate, join. They are designed around fast throughput, usually via columnar storage and parallel execution.
Put those workloads in the same engine and one tends to ruin the other’s day. So we split them, and pipelines did the shuttling (mostly one-way).
For a long time, this was perfectly acceptable because the whole system assumed lag. Your warehouse could be “a little behind.” “Next day” was the standard, metrics updated overnight, and reports were fine to run on a schedule.
That assumption is what changed.
The industry didn’t suddenly discover unification. In fact, we’ve been chasing it for years.
In-memory systems were one early attempt: if you keep enough data hot and execute fast enough, you can run analytics on operational data without collapsing performance. SAP HANA is the canonical example: it is an operational system designed to support real-time analytical workloads on the same data.
Hadoop and the early data lake era tried a different kind of unification: keep data on cheap storage and cut latency by scaling compute. It brought a lot to the table, but it remained largely batch-first, and making it feel relatively quick required serious engineering.
Then there was the “two-track” approach: Lambda-style designs that used streaming for freshness and batch for correctness. You could approximate real-time, but at the cost of duplicated logic, more systems, and more opportunities for “truth” to fork.
Those attempts to unify transactional and analytics data weren’t failures. They just made the trade-offs obvious: freshness, simplicity, isolation, and governance don’t come for free.
Here’s the real driver of today’s convergence: analytics got pulled into the point of decision.
Fraud is the classic example. If the model flags a transaction after it clears, that’s not fraud prevention, it’s a report. You want scoring while the transaction is still “in flight,” before authorization completes.
The same pattern shows up across financial workflows: credit decisions, AML screening, trading surveillance. The decision isn’t made in a monthly report; it’s made in an operational flow: approve, decline, hold, escalate.
It also shows up in customer experiences. Recommendations and personalization aren’t powered by last week’s segments. They’re powered by what happened seconds ago. “We noticed you clicked that” and “we noticed you clicked that last week” feel like two different products.
And now AI agents are amplifying the need. They often need a place to store state (memory, tool results, conversation context) and a way to pull governed business data while acting. That requires both low-latency operational reads/writes and deep analytical context tightly connected.
Once you accept that analytics is becoming part of the workflow, the old split starts to look less like best practice and more like a drag.
Separate transactional and analytical systems aren’t just two boxes. They’re a set of ongoing costs.
You store the same data in multiple places: inoperational DB, staging, warehouse, data lake, feature store, maybe a search index. Every copy needs access control, retention, lineage, and monitoring. Every copy can drift.
When numbers are wrong, you end up debugging the pipeline, not the logic: source, CDC, transform, load, semantic layer. The more systems, the more archaeology.
Latency becomes a product problem too. Not “how fast is the query,” but “how fast is the insight available where decisions happen.” A metric that arrives hours late can be technically correct and operationally irrelevant.
And governance gets harder. The more you spread sensitive data, the harder it is to guarantee consistent entitlements and auditability. Unification of transactional and analytical data, in practice, is often an attempt to reduce these multipliers.
Cloud warehouses made analytics dramatically easier to scale. With managed operations and an elastic compute, “big query” became normal. But the boundary remained: data still arrived from operational systems through pipelines.
Data lakes matured too. Table formats and better metadata turned object storage into something closer to a governed analytical substrate. The lakehouse framing resonated because it reduced silos inside the analytical ecosystem: one place to run data engineering, BI-style workloads, and ML training.
But the lakehouse, for most teams, still sat on the OLAP side. Operational databases were still “over there,” feeding “in here.”
So the next question became unavoidable: if analytics is now the platform’s center of gravity, how do we bring operational workloads closer without reintroducing the same integration mess?
This is where labels multiply (e.g HTAP (Hybrid Transactional/Analytical Processing), translytical, zero-ETL), but the intent is consistent: reduce data movement and shrink the loop from event to decision.
In practice, modern approaches tend to look like one of three shapes.
One is “same service boundary, different internal representations.” Azure Cosmos DB with Synapse Link fits here: Cosmos stays the operational store, and Synapse Link maintains an analytics-friendly representation so you can query without building the usual ETL chain. It’s not one engine doing everything, but it’s designed to remove a big category of custom integration.
Another is “make the operational database capable of serious analytics.” Google Cloud Spanner with Columnar Engine sits here. Spanner is chosen for transactional guarantees and scale; the columnar engine acknowledges that customers also want analytical queries on operational truth, without exporting, transforming, and waiting.
The third is “separate services, managed integration.” AWS Aurora + Redshift is the archetype: clear separation of concerns, plus tooling to keep them synchronized. It can be a very sane approach, but it still assumes two systems—and you still own the architecture of the seam, even if parts are managed.
Different shapes, same story: the market is compressing the distance between operational data and analytical decisions.
Here’s the twist: after years of “the lake is the center,” we’re seeing relational transactional systems, especially Postgres, pulled into the orbit of analytics platforms.
That’s not nostalgia; it’s a practical response to where teams are. Postgres is familiar, widely supported, and deeply embedded in application development. If you want to host operational state closer to analytics and AI, Postgres is the obvious bridge.
A premier example of this approach is Databricks Lakebase. It’s a Postgres-centric transactional service positioned as part of a broader analytics and AI platform. The promise isn’t “replace every OLTP database.” It’s: reduce seams, reduce copies, and make operational state feel native to the governed analytics/AI environment. It is about collapsing the operational/analytical loop for interactive data applications.
You can see similar moves elsewhere. Snowflake Unistore signals the same thesis: if your platform is where analytics happens, transactional capability becomes an adjacency you’ll be pushed into, mostly for data apps.
Google AlloyDB is arguably the closest conceptual cousin to Lakebase. It’s Postgres-compatible and leans into hybrid behaviors for teams that want modern operational performance without leaving the relational ecosystem.
Unified transactional + analytical platforms aren’t a fad. They’re a response to real-time workflows and AI-in-the-loop systems.
For data leaders, some of the most pressing questions are about time (both development and processing), resources (human and number/cost of systems), and governance.
Unified platforms can simplify the stack, reduce latency, and shorten the loop from event to action. They also force trade-offs into the open: isolation still matters, cost models still matter, and not every workload needs real-time.
But the trend line is hard to miss. Analytics isn’t just explaining what happened anymore. It’s increasingly part of driving what happens next. nd, sometimes, it is part of the transaction itself.
Explore more stories
From Junior Developer to Team Lead
This is the story of someone who never chased titles—just problems worth solving. Tamás Paulik, Head of Mobile Development, started from scratch with a university classmate, learning to sell, mentor, and lead. Today he leads the entire mobile development and mentors developers who are now mentoring others.
Bimodal Approach to GenAI Application Architecture
Dual-speed architecture helps you ship stable apps and iterate on AI fast—one product, two release pipelines, and clear contracts between them. Here’s how.
6 Hard Questions About the Impact of AI on Your Workforce
Research-backed answers on AI adoption, job transformation, and employee resistance. What the data reveals about layoffs, automation, and workforce planning.
