Summary: At the Data + AI Summit 2026, Databricks announced LTAP (Lake Transactional/Analytical Processing)—a Postgres-compatible transactional layer called Lakebase that mirrors writes into open columnar formats like Iceberg. The pitch: one copy of data, no ETL tax, analytics and transactions unified for AI agents. The engineering is real (~25,000 tps on open table formats). The terminology is where it gets slippery: architecturally, this is managed CDC with a fresh acronym, not classical HTAP—transactions land in Postgres, analytics read a columnar mirror with measurable lag. That distinction matters less for enterprise tabular estates than the marketing suggests, and more for AI developers, who face a different gap entirely: who owns the write path when your data is video, audio, embeddings, and model outputs—not just rows? That is where Pixeltable lives.
What Databricks announced#
Databricks framed LTAP as the "holy grail" of data architecture: transactions and analytics on one copy of data inside the lakehouse, using open formats, without the latency and cost of traditional ETL pipelines.
Under the hood, the architecture has two layers:
- Lakebase: A serverless, Postgres-compatible transactional engine for real-time writes—applications, AI agent tools, and operational workloads commit here first.
- Open columnar mirror: Committed data is replicated into Iceberg (or similar open formats) for analytical queries, historical context, and lakehouse-scale compute.
The headline performance claim—roughly 25,000 transactions per second on an open table format—is genuinely notable. Formats like Iceberg and Delta have historically struggled with small, frequent writes; hitting OLTP-scale throughput while staying open is a real engineering milestone.
Databricks positioned LTAP specifically for AI agent workloads: an agent needs to read fresh transactional state and query historical analytical context in the same session. LTAP promises both from one logical data estate.
LTAP is not HTAP—call the architecture what it is#
The database community reacted quickly, and the technical critique is straightforward: LTAP is not hybrid transactional/analytical processing in the classical sense. HTAP means one engine where committed transactions are immediately visible to analytical queries—same storage, no mirror, no sync window. LTAP does something different:
- Writes commit to Lakebase (Postgres-compatible OLTP)
- A background process replicates changes into Iceberg (OLAP)
- Reported sync lag is on the order of over a minute, not milliseconds
Strip away the keynote framing and you are looking at change-data capture with a managed sync path—CDC moved behind a platform API. That is not an insult to the engineering; fast, reliable CDC at lakehouse scale is hard and valuable. But calling it LTAP instead of HTAP is a category claim the architecture does not support. If your agent needs analytical reads to reflect a write that just landed, you need to know there is a sync boundary—and how long it takes.
Some defenders argue the dual-engine design is pragmatic: OLTP and OLAP optimize for conflicting storage patterns, and a unified interface over two specialized engines beats brittle ETL glue. That is fair. Shrinking mirror lag from minutes to seconds is an engineering problem. But pragmatism about the design does not make it HTAP. It makes it well-operationalized CDC—which enterprises have been building, under other names, for years (Kudu/Impala pipelines, feature-store mirrors, translytical lakehouses, and others).
Our read: Separate the engineering from the label. Databricks shipped credible transactional throughput on open formats—that is worth paying attention to. What LTAP is not is a new category that dissolves the OLTP/OLAP boundary. It is a polished sync layer with enterprise packaging. For builders, the useful question is not "HTAP or not?" but: where is the sync boundary, what is your freshness SLA, and does your workload even live in rows?
Write path vs. read path: the frame that actually matters for AI#
The LTAP debate maps cleanly onto a distinction we have made before in context graphs and decision traces:
- Read path (OLAP / lakehouse): Data arrives after decisions are made—via ETL, CDC, or mirror sync. Warehouses and lakehouses excel here: historical queries, BI dashboards, training-set preparation at scale.
- Write path (OLTP / operational): Data is created and transformed as work happens—inserts, model calls, agent actions, incremental recomputation. This is where decision context is still alive.
LTAP tries to shorten the distance between those two worlds for tabular enterprise data. Lakebase owns the write path; the Iceberg mirror serves the read path; Databricks provides one platform interface across both. Even with polished CDC, the sync boundary remains—marketing just makes it easier to forget.
That is the right problem for enterprise analytics teams. It is not the whole problem for AI application developers—because AI workloads add a third axis the OLTP/OLAP frame was never designed for: multimodal compute as data.
The multimodal divide LTAP does not address#
Consider what an AI application actually stores and transforms:
- Video files that expand into thousands of frames via iterators
- Audio transcribed by Whisper, chunked, and embedded
- Documents split into sections with per-chunk LLM summaries
- Images run through object detection, captioning, and similarity indexes
- Every model call producing structured JSON that feeds the next model
None of this is a row insert into Postgres followed by a mirror to Iceberg. It is a declarative pipeline where source media, derived views, embeddings, and model outputs form a dependency graph that must stay consistent as data changes.
SQL—and by extension Lakebase—can store metadata and tabular features. It cannot natively express "when this video is inserted, extract frames at 1 fps, transcribe audio, embed each chunk, and keep the similarity index current." That is why the multimodal data plane has no owner in the traditional stack, and why teams end up with the Frankenstein stack: S3 for blobs, Postgres for metadata, a vector DB for search, Airflow for orchestration, and Python glue holding it together.
LTAP solves the OLTP/OLAP split for rows. AI developers still need something that solves the multimodal write path.
Pixeltable: the multimodal write path LTAP validates but does not cover#
Databricks' announcement still validates a thesis Pixeltable has been building on: enterprises want fewer pipelines, fresher data, compute closer to where state lives. LTAP pursues that for relational lakehouse estates via managed sync. Pixeltable pursues it for multimodal AI workloads via declarative, incremental compute—no mirror lag between your video insert and its embeddings because there is no separate analytical copy to wait on.
We made the same argument when Microsoft shipped pg_durable: durable execution inside the system of record. LTAP extends that idea to the lakehouse scale for relational workloads. Pixeltable extends it one layer up—for the multimodal workloads that SQL, Spark, and Iceberg were never meant to express natively.
The parallel is direct:
| Dimension | Databricks LTAP | Pixeltable |
|---|---|---|
| Primary problem | Unify OLTP + OLAP on open lakehouse formats | Unify multimodal storage, compute, and retrieval for AI apps |
| Write path | Lakebase (Postgres-compatible) | Declarative computed columns over multimodal tables |
| Read path | Iceberg / Delta columnar mirror | Embedding indexes, similarity search, SQL-like queries |
| Sync model | Background CDC mirror (reported lag: minutes) | Incremental recompute—only changed cells update |
| Data types | Relational rows, JSON, vectors via extensions | Video, audio, images, documents, embeddings, model outputs |
| Agent use case | Query fresh transactional + historical analytical state | Capture decision traces, versioned lineage, retrievable context |
| Lakehouse bridge | Native (Iceberg is the analytical copy) | export_iceberg() for curated tabular outputs |
LTAP and Pixeltable are not competitors—they sit on different terrain. LTAP is a credible direction for enterprise tabular estates that already live on Databricks. Pixeltable is the write-path infrastructure for the multimodal AI layer that feeds those estates.
What the write path looks like in practice#
LTAP's agent story is: commit a transaction in Lakebase, then query historical context from Iceberg in the same session. Pixeltable's agent story is: declare the pipeline once, and every insert triggers incremental, versioned computation across modalities—with full lineage for audit and replay.
No separate ETL job to chunk documents. No manual embedding upserts. No orchestrator coordinating "step 1 → step 2 → step 3." The dependency graph, incremental updates, and version history are built in—properties a CDC mirror cannot give you for multimodal workloads.
Three lessons from the LTAP debate for AI developers#
1. Read the architecture, not the acronym#
New labels arrive every summit season. LTAP is the latest entry in a long line of "one copy of data" promises. The durable insight is architectural: where does data land first, where is the sync boundary, and what freshness can you actually depend on? If you are maintaining separate systems for storage, transformation, vectors, and orchestration, you are paying a pipeline tax—whether or not a vendor hides it behind a platform API. Declarative, incremental pipelines are how you pay down that tax for multimodal work.
2. Lag semantics matter—know your SLA#
Unified branding does not mean unified freshness. LTAP's mirror lag is the reminder: operational writes and analytical reads are not the same moment. If your agent needs sub-second consistency between a write and an analytical read, map the sync boundary explicitly. Pixeltable's incremental model recomputes affected cells on insert rather than batch-syncing whole tables—but expensive model calls still have latency you must design for. Be explicit about what "real-time" means in your architecture.
3. Own the write path; integrate with the read path#
Enterprise AI stacks will have lakehouses for analytics—that is not going away. The strategic choice is whether your AI application logic lives in the write path (where data is born and transformed) or gets bolted on as downstream ETL. Pixeltable owns the write path for multimodal AI; Iceberg export hands curated results to Spark, DuckDB, Snowflake, and BI tools on the read path. Complementary, not competitive.
A complementary architecture, not an either/or choice#
We mean that literally. A mature enterprise AI stack might look like:
- Pixeltable — multimodal ingestion, model pipelines, embedding indexes, agent context, versioned lineage on the write path
- Iceberg export — curated tabular features, labels, scores, and summaries streamed to the lakehouse
- Databricks / Spark / warehouse — large-scale analytics, training data preparation, BI dashboards on the read path
- Lakebase / LTAP — operational transactional workloads that need Postgres semantics at lakehouse scale
Each layer does what it is optimized for. The mistake is forcing one tool to cover all four—or rebuilding the Frankenstein stack because no layer owns multimodal compute.
This is the same "infrastructure, not lock-in" posture we take in the AI database landscape guide and building production AI agent systems: choose the right engine for each job, but minimize the glue between them.
People also ask#
Is Databricks LTAP true HTAP?#
No—not by the definition database researchers and practitioners use. HTAP requires a single engine where analytical queries see committed transactions immediately. LTAP commits to Postgres and mirrors to Iceberg with reported lag measured in minutes. That is managed CDC with a unified platform interface, which can be very useful, but it is a different architecture than HTAP. The acronym is new; the pattern is not.
Does LTAP replace a vector database or AI pipeline tool?#
No. LTAP addresses the OLTP/OLAP boundary for tabular data. AI applications still need multimodal processing, embedding management, model orchestration, and retrieval infrastructure. Those workloads live on a different layer—the multimodal write path—that LTAP does not target.
How does Pixeltable relate to Databricks?#
Complementary layers, not substitutes. Pixeltable is declarative AI data infrastructure for multimodal pipelines on the write path. Databricks is enterprise-scale lakehouse analytics on the read path. Many teams will use both: build and iterate on multimodal pipelines in Pixeltable, export curated outputs to Iceberg, and analyze at scale on Databricks or any Iceberg-compatible engine. We ship Iceberg export precisely because lakehouse platforms belong in a healthy stack—not because we are trying to replace them.
Conclusion#
Databricks LTAP is worth understanding: credible transactional throughput on open formats, Postgres-compatible writes, and a clear bet that AI agents need both operational and historical context. It is also worth reading precisely: managed CDC, not HTAP—and the label matters because agents and applications depend on freshness guarantees the marketing slide does not spell out.
For AI developers, the takeaway is sharper: the industry is finally polishing the OLTP→OLAP sync path for tabular data. The multimodal divide—video, audio, embeddings, model outputs, agent decision traces—is still wide open. That is the problem Pixeltable was built to solve: one logical copy of multimodal data, declarative compute on the write path, incremental maintenance instead of mirror lag, and open bridges to the lakehouse when you need analytics at scale.
When the largest platforms move toward "compute close to data," the question is not whether that trend is real—it is which data, and which compute, your application depends on.
To explore the multimodal write path:
- Start with the Pixeltable docs and
pip install pixeltable - Read Who Owns the Multimodal Data Plane?
- See Iceberg export for lakehouse analytics
- Build agent context with context graphs and decision traces
- Compare approaches in the AI database landscape guide
