Databricks just unified OLTP and OLAP on one lake. That removes copies — it doesn’t make an automated decision fresh under concurrency. Here’s where the two architectures actually solve different problems.
TL;DR: At Data + AI Summit 2026, Databricks launched LTAP — Lake Transactional/Analytical Processing — built on its managed Postgres engine, Lakebase. The promise: transactional and analytical workloads on the same data, in the same place, with no pipelines syncing an operational store to a warehouse. That’s a real win for data plumbing. But “same place” is not the same as “at the same time.” LTAP doesn’t promise that the data is fresh and consistent at the instant a high-stakes automated decision reads it — while thousands of those decisions run at once. That “same time” guarantee is what a Context Lake provides: derived context (velocity counters, exposure totals, similarity signals) kept current under concurrency inside a tight validity window. It’s the difference between a tidy data platform and a fraud charge that doesn’t slip through during a spike. The two layers can sit in the same stack.
Databricks LTAP puts transactional and analytical workloads on the same data, in the same place. What it doesn’t promise is that data being correct at the same time — fresh and coherent at the instant a high-stakes automated decision reads and acts on it, while thousands of those decisions run at once. Keeping derived state correct at decision time — computing it, maintaining it as events arrive, owning it when the decision writes back, and coordinating concurrent access — is what a Context Lake does. “Same place” is a storage property. “Same time” is a systems property, and it’s the one that decides whether the decision is right.
On June 16, 2026, Databricks introduced LTAP, described as the first Lake Transactional/Analytical Processing architecture. It builds on Lakebase, the fully-managed, serverless Postgres engine Databricks now ships, and folds it together with the lakehouse under one governance model and one storage layer.
The pitch is clean: transactional and analytical workloads run on a single copy of data, so there are no pipelines syncing an operational store to a warehouse, no replicas to reconcile, no connectors moving rows between systems. Operational and analytical results stay in sync because there’s only one copy to read.
If you’ve read anything we’ve written about the coherence problem in the modern data stack, that framing will sound familiar — which is exactly why it’s worth being precise about what LTAP does and doesn’t change.
Two pieces matter here:
Lakebase is a managed Postgres engine with separated compute and storage, instant branching, and native sync from Unity Catalog tables. It’s a capable OLTP database — point reads and writes for transactional apps, plus a path to use it as an online feature store or an agent state store.
LTAP is the architecture that puts Lakebase and the lakehouse on the same governed storage. The headline benefit is the elimination of the operational-to-analytical pipeline: your app writes to Postgres, your analytics read the same governed data, and you don’t maintain ETL or a separate warehouse copy to keep them aligned.
That’s a genuine simplification for a large class of workloads. If your pain is “we maintain three copies of the same table and they drift,” LTAP attacks that directly.
We’re not going to pretend there’s no overlap. Both architectures reject the idea that you should maintain divergent copies of state across systems and hope they line up. Both target AI applications and agents that need current data. Both want to collapse a sprawl of pipelines into something coherent.
So the interesting question isn’t “who eliminates copies.” It’s what each layer actually does with the data, and where the remaining gap lives once the copies are gone.
A Context Lake does one thing well: it keeps the context a decision needs correct at the moment the decision happens — computing that context, maintaining it as events arrive, owning it when the decision writes back, and coordinating the concurrent decisions reading and updating it. That’s more than serving a read; it’s running the transform, the state, and the concurrency control as one system.
That matters when a decision runs inside a tight validity window — roughly 10ms to one second — with no human in the loop and real money on the line: a card authorization, a fraud check during a burst, a margin or liquidation call while prices move, an agent acting on derived state. Inside that window, the decision depends on derived context: velocity counters, rolling aggregates, exposure totals, similarity signals. Not a single stored row — context that has to be computed from a stream of events, kept current, and reconciled across everything happening at once.
Here’s the part unifying storage doesn’t solve. Removing the copy between OLTP and OLAP doesn’t compute that derived context for you, and it doesn’t keep it coherent under concurrency. You still have to maintain the velocity counters and aggregates, keep them current as events arrive, and reconcile them while many concurrent decisions read and write the same state. That’s the structural gap — and it’s the same gap whether the underlying store is one copy or three.
A Context Lake closes it deliberately: derived context is maintained as incrementally-maintained views that converge sub-second as events arrive, modeled in hybrid row/columnar tables so a point lookup and an aggregation scan hit the same current state, and — where the Context Lake owns the state a decision writes back — committed under ACID with concurrent updates serialized. Every decision works from one internally coherent snapshot, so two concurrent decisions don’t act on two different versions of reality.
The cleanest way to hold both architectures in your head: LTAP puts your transactional and analytical data in one place. A Context Lake keeps the derived state correct at decision time — and runs the transform, the state, and the concurrency control to do it.
Lakebase is a strong general-purpose Postgres OLTP engine, and that’s the point — it’s general-purpose. The real-time decisioning problem isn’t “can I do a fast point read.” It’s “can I compute fresh derived state from a high-velocity event stream, keep it coherent, own it when a decision writes back, and coordinate everything reading and updating it at once — before each decision commits.” A general OLTP database hands that back to you: you build the materialized views, you wire the freshness, you manage the contention — and you’re back to the pipeline and divergence problems LTAP was supposed to retire, just inside one platform instead of across three.
This isn’t a benchmark claim and we’re not making one. It’s an architecture claim: the two do different jobs, and the seam between them is the compute-maintain-and-coordinate-derived-context-under-concurrency problem that storage unification leaves untouched.
| Dimension | Databricks Lakebase + LTAP | Tacnode Context Lake |
|---|---|---|
| **What it is** | A unified store: OLTP + OLAP + streaming on one governed copy | A system that computes, maintains, and coordinates the context decisions run on |
| **Problem it solves** | Copy sprawl; ETL between operational and analytical stores | Fresh, coherent derived state at decision time, under concurrency |
| **Derived context** | You build and maintain it (Postgres MVs, jobs) | Computed and incrementally maintained — IMVs, on-demand aggregation, vector/semantic signals |
| **State ownership** | Stores your tables | Can own the state a decision writes back (derived signals, agent state) — in the write path, ACID, concurrent writes serialized |
| **Concurrency** | General-purpose Postgres + lakehouse | Concurrent decisions read and update one internally coherent snapshot |
| **Heritage** | Lakehouse + managed Postgres, broad data platform | Purpose-built for real-time decisions, hybrid row/columnar |
| **Adoption shape** | Adopt the platform | Sits with your system of record — reads from it, owns the state it derives |
Be honest about the fit. If your problem is copy sprawl — an operational Postgres, a warehouse, and a pile of connectors keeping them aligned — and your reads are app queries and analytics rather than sub-second automated decisions under concurrency, LTAP is a sensible consolidation. If you’re already deep in the Databricks platform and Unity Catalog is your governance backbone, the integration story is hard to beat on operational simplicity.
You still need a Context Lake when the gap isn’t where data lives but whether the decision sees fresh derived state in time: fraud velocity during concurrent bursts, exposure limits shared across simultaneous transactions, liquidation calls under price volatility, agents acting on derived context at machine speed. Those are decisions, not queries, and they fail on freshness and coherence under concurrency — not on how many copies of a table you keep.
The honest relationship here isn’t rivalry. A Databricks lakehouse — with or without LTAP — is a perfectly good system of record, and a Context Lake can read from it via change data capture. But a Context Lake isn’t only a reader sitting downstream. It computes and maintains the derived context decisions need, and when it owns that state — the derived signals, the agent state, the running totals a decision writes back — it’s the authoritative system for it: in the write path, with ACID guarantees and concurrent updates coordinated. Databricks unifies the operational and analytical estate; the Context Lake owns the real-time decision layer on top of and alongside it.
Unifying your data platform is worth doing. Just don’t assume it makes your automated decisions correct under load. Those are two different problems, solved by two different layers.
Former Cockroach Labs. Tells stories about infrastructure that actually make sense.
Book a demo and discover how Tacnode can power your AI-native applications.
Book a Demo