DEV Community: Itay Waisman

LTAP: Unifying Storage Isn't the Same as Unifying Resource Utilization

Itay Waisman — Wed, 08 Jul 2026 09:33:10 +0000

The reaction to LTAP has mostly been about correctness: what happens to a transaction that commits in Postgres but hasn't finished converting into Delta format yet, and whether "immediately queryable" has an actual bound. Those are fair questions. But there's a second problem sitting underneath the first one that almost nobody in this conversation is asking about, and it's the one that shows up on your cloud bill, not in your consistency model.

One disclosure: I'm from Regatta, where we build RegattaDB around the same problem LTAP is addressing. What follows is a technical argument about resource utilization, not a claim about correctness, which the previous piece already covered.

The Question Storage Unification Doesn't Answer

Say you've solved the data-copy problem. Transactional and analytical workloads now read from the same physical bytes. Great. Now run them concurrently on the same cluster and ask a different question: what's actually happening to your buffer cache?

In almost every database architecture, including the one underneath Lakebase, each node manages its own buffer pool as a private, per-node resource. When a large analytical scan runs, it pulls cold data through that node's cache, and in doing so it evicts whatever transactional working set was sitting there. When the transactional workload picks back up, it has to re-warm the cache the analytical query just flushed. Unifying the storage layer doesn't change this. Postgres's buffer cache and Spark/Photon's execution memory are still two separate resource pools contending for the same physical RAM underneath, even when they're pointed at the same Delta files.

This is why conventional database deployments, even well-tuned ones, typically sustain only 20 to 40 percent hardware utilization. Not because the hardware is idle. Because most of it is reserved as headroom against exactly this kind of cache-eviction storm, the moment a heavy analytical query collides with transactional traffic.

What Sharing Actually Means

The fix isn't giving OLTP and OLAP the same storage. It's giving them the same buffer, cluster-wide, so that a scan on one node doesn't force cold reads on another.

RegattaDB shares peak buffer capacity across the entire cluster instead of walling it off per node. A node running a heavy scan can draw on buffer capacity sitting idle elsewhere in the cluster rather than evicting the transactional cache it's sitting next to. The result is sustained utilization around 85 percent, against the 25 percent baseline conventional architectures need as safety margin. In practical terms, that's the difference between needing 40 servers to safely run a mixed workload and running the same workload on 10.

That's not a benchmark trick. It's a direct consequence of not treating memory as a per-node private resource in a workload that was never going to stay confined to one node's access pattern.

Why This Gets Missed

It gets missed because "unified storage" is a diagram you can put on a slide, and "sustained cluster-wide buffer utilization under concurrent mixed load" is not. The first is a satisfying story about where bytes physically sit. The second requires someone to actually run both workloads at once, for long enough, and measure what the hardware was doing the whole time.

Nobody publishes that number by accident. It's genuinely harder to get right, and it's the number that determines whether "unified" data architecture actually saves you money, or just saves you an ETL job while your infrastructure spend stays exactly where it was.

The Question Worth Asking Instead

Before the storage diagram, ask the operations question: under a realistic mixed workload, at steady state, what percentage of provisioned compute and memory is actually doing useful work? If the honest answer is somewhere in the 20 to 40 percent range, unifying where the data lives hasn't touched the part of the bill that actually matters.

That number is measurable, publishable, and, as far as I can tell, still missing from this conversation.

Why Your Database Is the Actual Bottleneck for AI Agents

Itay Waisman — Wed, 01 Jul 2026 14:19:20 +0000

AI agents are not a compute problem. They are a data problem.

Most of the conversation around agentic AI focuses on model capability: better reasoning, longer context windows, smarter planning. That matters. But the thing that actually breaks agent systems in production is underneath all of that. It's the database.

Here's the specific failure mode. An agent needs to do three things at once: read live operational state, run analytical reasoning over historical data, and execute a transaction based on what it finds. In most architectures today, those three operations touch three different systems. The state lives in Postgres. The analytics run against a warehouse. The vector context comes from a separate store. By the time all three queries complete and the agent is ready to act, the data from the first query may no longer reflect reality. The agent acts on a picture of the world that has already changed.

This isn't a model failure. The model reasoned correctly. It reasoned on stale data.

The triangle problem

Combining OLTP and OLAP in a single system has been attempted many times. The reason it hasn't worked is what engineers call the triangle problem: you can optimize for speed (transaction throughput), scale (data volume and concurrency), or efficiency (cost per operation), but not all three without making real tradeoffs. Every previous attempt at HTAP has hit this constraint in one form or another.

The approaches that failed generally tried to solve this as a compute problem: build a faster query engine, add more memory tiers, route workloads to different compute paths. The result was always a system optimized for one workload type that tolerated the others.

A different starting point

The approach that actually works starts at the storage layer, not the compute layer. When the storage architecture is designed from the beginning to serve both row-oriented transactional access and columnar analytical scans against the same data, the tradeoffs change. The reason OLTP and OLAP conflict in traditional systems isn't that they need different compute. It's that they need different data layouts, and conventional storage can only serve one.

Combined with a concurrency control protocol that doesn't block analytical queries with transactional locks (and doesn't force analytical queries to stall transactional cleanup), you get a system where both workloads actually run concurrently rather than taking turns.

What the numbers look like in practice

Two specific benchmarks demonstrate this:

Transactional throughput under mixed load
TPC-C at 200,000 warehouses, 10 nodes, 14 cores each. 12.86 tpmC within the 99% threshold. The benchmark ran with OLAP queries executing against the same data concurrently. No degradation. Most databases that publish TPC-C numbers run it in isolation, without simultaneous analytical load.

Analytical throughput under concurrent write pressure
A JOIN across two 10 billion row tables, all rows distributed across nodes with no co-location, no indexes. Simultaneously: 50,000 ACID-compliant writes per second against the same data. 50 instances, 64GB RAM, 4 cores each. The JOIN completed in 174 seconds. Every write committed. No contention between the two workloads.

The reason that second benchmark matters specifically for agent workloads: an agent that is reading analytical context while other agents are writing state changes to the same records needs both operations to complete correctly. In a fragmented architecture, those two operations are in different systems with different consistency guarantees. In a system with a single concurrency model, they're the same transaction.

What agents actually need

Agents need three things from a database that most databases don't provide together:

Transactional correctness at concurrency. Not 10 concurrent users. Hundreds or thousands of concurrent agent instances reading and writing shared records. Serializable isolation that holds across distributed nodes, not just within a single instance.

Analytical reasoning on live data. Not yesterday's snapshot from last night's pipeline. The ability to run a complex analytical query against data that is current at query time, in the same operation as a transaction that acts on the result.

Natural language access. Agents should be able to query data the same way a person would ask a question. An MCP-native interface that lets any agent issue natural language queries against live operational data, without SQL knowledge or predefined query templates, is what closes the loop.

The full technical breakdown of how this works at the concurrency model and storage layer level is in the original post: The Shift to Agentic AI and a Modern Database

Can Databricks LTAP Actually Run OLTP and OLAP at the Same Time?

Itay Waisman — Tue, 30 Jun 2026 11:09:18 +0000

Databricks announced LTAP, Lake Transactional/Analytical Processing, at Data + AI Summit this week. The pitch is clean: write transactional data once, and have it usable for analytics without a CDC pipeline in between. I read through what's public and want to dig into the parts the keynote slide doesn't answer.

Quick disclosure up front: I run Regatta. We build RegattaDB, which is going after the same root problem, no separate OLTP, OLAP, and vector stacks. I'm not a neutral party here. But the technical questions below are ones any architect evaluating this should be asking regardless of who's doing the asking.

What actually shipped

Lakebase, Databricks' serverless Postgres service built on object storage is GA. LTAP is the architectural layer on top of it. Instead of writing rows in Postgres format and running CDC to convert them into columnar format for the Lakehouse later, Lakebase now writes directly into Delta and Iceberg formats at the point of write, via copy-on-write. Same physical data, from the moment it lands, for both sides.

Worth checking the status before you architect around it: LTAP itself is listed as "coming soon." Lakehouse//RT, the compute engine behind the sub-100ms analytical query claim, is in beta. If you're designing agent infrastructure today against this announcement, you're designing against unshipped product.

Why this problem is hard in the first place

OLTP wants low-latency random I/O for point reads and writes. OLAP wants high-throughput sequential scans across large datasets. Vector search wants approximate nearest-neighbor lookups over high-dimensional embeddings. Each of these wants a different data layout to perform well, and optimizing one tends to hurt the other two. That's the actual reason CDC pipelines and zero-ETL connectors exist, not because anyone loves pipelines, but because keeping the engines separate and syncing them was the only way to avoid resource contention. It doesn't resolve the underlying tension. It relocates it to a sync boundary.

What LTAP does (and doesn't do)

LTAP doesn't merge the two engines. Postgres still handles transactions. Spark and the Lakehouse still handle analytics. What changes is the storage layer underneath both of them, copy-on-write buffering removes the pipeline that used to connect them. That's a legitimate engineering contribution to the "stop paying the CDC tax" problem. It is not the same thing as a single execution engine.

The part that needs more detail: the flush window

Here's the path, as best I can reconstruct it from public material: Postgres writes to WAL and buffer cache first. A caching layer converts rows to columnar format. Data then lands in Delta or Iceberg in object storage.

That conversion step is doing a lot of work, and it sits between two separate consistency domains, Postgres ACID on one side, Delta snapshot isolation on the other. The gap between them is a flush window, and as far as I can tell, it's unbounded in anything Databricks has published.

Concretely: a long-running Spark query reads a snapshot as of when it starts. A transaction that commits in Postgres after that point being invisible to the query is expected and fine. The harder case is a transaction that committed before the query started but hasn't finished converting and flushing yet. Is the analytical result just stale, or is it actually wrong? Databricks describes data as "immediately queryable" without defining what immediately means under sustained load. That's not a gotcha, it's a genuinely open question, and I'd want a number before I built agent logic on top of it.

This matters specifically for agents. An agent that reads live transactional state, joins it against historical data, and writes back a decision is crossing an engine boundary regardless of how the storage underneath is organized. LTAP removes the data movement cost of that crossing. It doesn't remove the crossing itself.

What the benchmark shows — and doesn't

The published number for Lakehouse//RT is against TPC-H Q6: a single-table scan with a filter and a simple aggregation. That's a reasonable test of scan speed, predicate pushdown, and vectorized execution. It does not test joins. There's no published number yet for multi-table analytical queries running concurrently with high-frequency transactional writes, which is the workload that actually matters for the unification claim.

The third workload nobody's talking about

LTAP addresses OLTP and OLAP at the storage layer. Vector search is still an extension bolted onto the Postgres side, with the contention and single-node ceiling that come with bolting a high-dimensional ANN workload onto a row-oriented transactional engine. All three workloads, transactional, analytical, semantic, have genuinely different compute profiles. Solving two of three at the storage layer is real progress. It's not the full problem.

What unifying all three actually takes

Full disclosure again: this is the part where I'll tell you what we did differently, because we made the opposite bet, that you can't bolt this together, the concurrency model has to be designed for all three workloads from day one.

A few of the specific decisions that came out of that constraint:

Storage layout: log-structured rather than slotted pages, which avoids the read amplification of sparse page layouts and the TOAST indirection overhead Postgres carries for variable-size rows.
Version cleanup: precise metadata on exactly which row versions become unneeded the moment a snapshot is removed, no crawling, no dependency on the oldest active snapshot. Long-running analytical queries don't stall transactional cleanup.
Indexing: indexes point to a stable Row ID rather than a physical location, so updates to non-indexed columns don't touch the index at all.
Caching: logical, row-level caching instead of physical page caching — a 100-byte hot row occupies 100 bytes of cache, not the 8KB page it happens to share with cold data.
Scale: native horizontal scale, distributed joins and cross-node ACID transactions hold regardless of how data is distributed, no sharding layer, no application-side compensation logic.
Concurrency: a single protocol combining optimistic and pessimistic locking, built as a starting constraint rather than layered on afterward.

That gives you one schema, one connection, one concurrency model across all three workload types, not three systems sharing a storage layer.

Questions worth asking any vendor here, including us

Does the system maintain serializable consistency across millions of concurrent reads and writes?
Does it scale linearly without sharding?
Does a query cross an engine boundary even if the underlying data doesn't have to move to get there?
What's the actual published bound on read-after-write visibility under load?

LTAP is the right diagnosis, fragmented data is the bottleneck for agent systems. It just stops short of a unified execution model. If anyone's dug further into the LTAP docs than what's public so far, I'd genuinely like to see it, and if Databricks publishes the flush bound, I'll update this.

Your AI Agents Are Only as Smart as Your Database

Itay Waisman — Tue, 23 Jun 2026 10:28:39 +0000

The problem isn't the model. It's the data layer.

Every production agent system I've seen hit the same wall, and it's never the LLM.
It's the database.
The standard enterprise data stack looks something like this: a transactional database (Postgres, Oracle, MySQL) for operational writes, a warehouse (Snowflake, Databricks, Redshift) for analytical queries, a vector store (Pinecone, Weaviate, pgvector) for embeddings — all stitched together with CDC pipelines, ETL jobs, and enough custom orchestration code to keep three data engineers employed indefinitely.
For humans making occasional queries, that architecture mostly holds. Humans are slow. A 15-minute pipeline lag is annoying. It's not a correctness problem.
For AI agents, a 15-minute lag means acting on a world that no longer exists. An agent evaluating a fraud signal on data that's 12 minutes stale isn't hallucinating. It's reasoning correctly on incorrect information. That's a data architecture problem, not a model problem.

Why agents break this architecture specifically

Agents don't browse your data. They hammer it.
A production deployment isn't one agent making thoughtful queries. It's hundreds or thousands of agent instances reading, writing, and reasoning simultaneously. Each one needs:

Live transactional state, what is the current account balance, order status, session record?
Analytical context, what patterns exist across 18 months of behavioral history?
Semantic similarity, does this situation match anything we've seen before?

In a fragmented stack, those are three separate systems with three separate consistency models. Getting all three to reflect the same moment in time requires cross-system transactions that don't exist. You're not just dealing with pipeline lag. You're dealing with fundamental consistency gaps between systems that were never designed to coordinate.
The fraud detection use case makes this concrete. An agent needs to evaluate a live transaction (OLTP), compare it to behavioral history and velocity metrics (OLAP), and match it against known fraud pattern embeddings (Vector), all in a window measured in milliseconds. In a fragmented stack, by the time data moves between systems, the authorization window has already closed.

The triangle problem and why it was unsolvable until recently

People have tried to solve this before. Every attempt runs into what we internally call the triangle problem: when you're designing a distributed database, you're constantly making tradeoffs between speed (transaction throughput), scale (data volume and concurrency), and efficiency (cost per operation). Optimize hard for two, and the third suffers.
Traditional HTAP systems tried to bridge OLTP and OLAP by maintaining separate row-store and column-store replicas in the same system. It works, up to a point. But "the same system" often means two engines with an internal sync mechanism — which is a pipeline, just a shorter one. And vector search is usually bolted on after the fact, not integrated into the core execution model.
The storage and concurrency model is what determines whether you can actually close the triangle. Most distributed databases treat storage as a solved problem and focus on compute and consensus. RegattaDB took the opposite approach — rethinking the storage layer first, then building a concurrency control protocol that doesn't require distributed locks, consistent snapshots, or clock synchronization.
The practical consequence: read-only analytical queries never block writing transactions. Concurrent OLTP and OLAP workloads share the same compute. And the cluster-wide resource pooling means you don't overprovision per-node for peak demand — the whole cluster handles spikes, so you need roughly 15% headroom instead of the ~75% that conventional databases hold in reserve per server.

What this looks like under real load

Two benchmarks are worth understanding, because they're specifically designed to test the claims that matter for agent workloads.
The TPC-C run: 750,000+ transactions per second, sustained across a 50-node GCP cluster at 1.5 million TPC-C warehouses, at 98% tpmC efficiency. This is a contention run under real mixed load — not a peak score on a clean dataset. Full CPU, I/O, and latency data is published.
The 20-billion-row JOIN: Two tables of 10 billion rows each, randomly distributed across 50 nodes, no indexes, no data co-location, no sharding on the join key. The JOIN completed while executing 50,000 ACID-compliant updates per second concurrently on the same data. On standard cloud hardware. No tuning.
The second benchmark specifically tests the "OLTP and OLAP simultaneously" claim. Most databases can execute a large JOIN. Most can handle concurrent transactional writes. Very few can do both at scale on the same live data without either the analytical query degrading or the transactional writes losing consistency guarantees.

What this actually changes for agent architectures

If you're designing an agent system today, the data layer decisions you make now have long-term consequences.
Every agent workload you add to a fragmented stack adds more pipelines to maintain, more schema drift to manage, and more failure modes to debug. That overhead compounds. The architecture that works for three agents starts to crack at three hundred.
A unified data layer, where OLTP, OLAP, and vector search run in the same engine against the same live data — isn't primarily a cost play (though the TCO numbers are real: 50–70% infrastructure footprint reduction, 50–60% license cost reduction). It's an architectural foundation question. Does your data layer scale agent capability, or constrain it?
The organizations getting ahead on agent systems aren't deploying the most agents. They're the ones who resolved this question at the infrastructure layer before it became a production incident.

The boring operational truth

Multi-agent systems introduce a class of data problem most teams haven't encountered before: hundreds of agents reading and writing the same records simultaneously. Traditional databases handle this within a single node. Distributed agent workloads break those guarantees unless the concurrency model was specifically designed for them.
That's not a scary problem. It's a solvable one. But it requires knowing the problem exists before you're debugging race conditions in production at 3am.
If you're mapping out the data layer for an agent system and want to dig into the architecture or the benchmarks in more detail, the full technical write-ups are at regatta.dev/blog.The concurrency control post in particular is worth reading if you care about how serializable isolation actually works at distributed scale — no locks, no snapshots, no clock sync required.