The Lakehouse Freeway, Part 3: Real-Time Data + AI on One Platform

Part 1 established the governed data foundation. Part 2 added a canonical Unified Data Model (UDM) with explicit business meaning and defined consumption paths. Together, they form a useful architecture with operational systems staying where they are.

Pattern 3 extends that foundation for selected workloads. The Data + AI Beltway brings product transactions, curated data, applications, and AI into a tighter loop. It is an architectural option, not the destination every organization must reach.

The Data + AI Beltway: Pattern 3

Pattern 3 consolidates selected product operational databases onto Lakebase Postgres and closes the loop between operations and AI. Products still own their records. What changes is where those records live, and how operational changes reach the curated model that applications and agents use.

Pattern 1 was deliberately one-way: the platform never writes into product databases. Pattern 3 keeps that rule. Moving product OLTP onto Lakebase brings transactional storage and the lakehouse onto one platform. The loop still needs explicit write ownership, permissions, and curation contracts.

The loop runs product write → Lakehouse Sync → Medallion → UDM → synced read schemas → apps and agents. Sources that remain on their existing platforms keep using Pattern 1 ingest.

1. Centralized, product-owned OLTP

Each product gets its own Lakebase project, so compute, scaling, and release cadence stay independent. Only the owning product's service identity can write its schemas. The platform owns separate, SELECT-only UDM read schemas, exactly as in Pattern 1.

Lakebase provides managed Postgres capabilities such as autoscaling, zero-copy branching, and point-in-time recovery. Availability, restore, scaling, and access configurations must match the product's requirements.

Tenant isolation is chosen per product:

Whatever a product uses in OLTP, the lakehouse and UDM keep structural tenant separation. Nothing joins across tenants without an explicitly approved data product.

2. The near-real-time loop

• Commit. A product writes to its own Lakebase schema.
• Capture. Lakehouse Sync reads the Postgres write-ahead log and lands every insert, update, and delete in a Unity Catalog Delta table, batched about every 15 seconds (Databricks).
• Curate. Streaming pipelines mask PII, enforce expectations, and promote changes into the canonical UDM using the Pattern 2 schema registry.
• Publish. Continuous synced tables project the UDM back into Lakebase read schemas.
• Consume. Apps and agents read through the GraphQL gateway; analysts and Genie read Gold directly.

Freshness is measured end to end, from product commit to UDM-visible, with per-tenant alerts against an SLA. A product reading its own records never waits for the loop; it reads its write schema directly. The loop serves cross-product and AI consumers who need the canonical view.

3. One multi-tenant Data + AI plane

AI capabilities use the same governed UDM and business definitions through the paths established in Pattern 2. Retrieval indexes and agent memory are derived or workload-specific stores; their tenant boundaries and refresh behavior remain explicit.

4. Agents that act, safely

Pattern 2's graph is read-only. In the Beltway, GraphQL mutations let apps and agents act through product-owned paths. These controls can also apply to existing product APIs without an OLTP migration:

• A mutation resolves to the owning product's write path — never to UDM tables or another product's store.
• Every agent action carries both the agent's identity and the delegating user or tenant, and both are audited.
• High-impact actions require human approval or a policy check before commit.
• The resulting write re-enters the loop like any other, so every consumer sees it with lineage back to the action.

These controls address part of Gartner’s concern about “inadequate risk controls”: agent actions need explicit authorization, approval where required, and an audit trail alongside data governance.

5. Migrating one product at a time

Stable UDM and application read contracts let selected products move to Pattern 3 individually:

• Convert engine-specific code (T-SQL, procedures, triggers) to Postgres and rehearse on a zero-copy Lakebase branch.
• Dual-run: keep Pattern 1 CDC from the legacy database while the new write path is validated.
• Cut over writes and retarget the GraphQL resolvers.
• Swap Lakeflow Connect CDC for Lakehouse Sync, reconcile, and retire the legacy database.

Downstream read contracts can remain stable while the write and capture paths change. Validate keys, values, permissions, and freshness before retiring the legacy path.

6. LTAP: the storage direction

In June 2026, Databricks announced LTAP (Lake Transactional/Analytical Processing), which runs OLTP and OLAP on a single copy of data in open Delta and Iceberg formats, governed by Unity Catalog. It's "coming soon as part of Lakebase" (Databricks).

Analytical queries read a consistent, up-to-date snapshot while Postgres serves none of that read traffic, so large analytical jobs don't slow transactions (Databricks). That maps directly to DevIQ Pattern 3: once product OLTP lives on Lakebase, the loop from transaction to curated UDM to AI becomes near-real-time, without ETL copies in between.

For Lakebase-native sources, LTAP’s target is to remove the separate CDC capture-and-copy hop: transactional and analytical engines read a single copy of product data. That is the announced direction, rather than a prerequisite for today’s Lakehouse Sync loop.

The contracts don't change: products still own writes, the UDM is still curated, and apps and agents still read through GraphQL. DevIQ designs Lakehouse Sync as a replaceable capture step for exactly that reason.

When the Beltway fits

The Beltway is attractive when a product fits Postgres, cross-product freshness matters, and bringing operational storage onto the data platform simplifies the architecture enough to justify migration.

The commitments are concrete: convert engine-specific behavior, rehearse cutover and rollback, size transactional workloads, define tenant isolation and restore boundaries, and measure end-to-end freshness. Hosting the pieces together does not remove those responsibilities.

Retain the existing operational platform when specialized database features, established service levels, regulatory constraints, or migration risk outweigh the benefits of convergence. Patterns 1 and 2 still provide governed data and shared meaning through the existing ingest paths.

The three patterns at a glance

Build the freeway; choose the extension

The value of the architecture is reuse: ingestion, quality controls, business definitions, and governed access become shared assets rather than separate work inside every application or AI project.

Start with Pattern 1's governed foundation. Add Pattern 2's canonical UDM and explicit business meaning around the domains your use cases need. Choose Pattern 3 where operational convergence is a good fit.

The Beltway extends the freeway. It does not replace it, and the freeway is useful without it.

Ready to assess where the Beltway fits? Talk to DevIQ about a UDP readiness assessment. We’ll map your sources, identify your first high-value data products, and assess which operational workloads should remain in place or move onto Lakebase.

Previous: The Lakehouse Freeway, Part 2: Shared Business Meaning for Apps and Agents

Start the Series: The Lakehouse Freeway, Part 1: Your AI Strategy is a Data Architecture Problem