Sub-Second on the Lakehouse

How Auraa Serves APIs from Databricks Without Breaking the Single Source of Truth

Delta Lake through a SQL Warehouse is not a sub-second point-read engine. Most teams fix that by adding a second database, and the moment they do they have two sources of truth, two governance perimeters, and two audit trails.

Read the white paper

Key takeaways

Delta stays authoritative

Lakebase holds a read copy that can be rebuilt from the audit trail.

Dual-surface reads

One governed state serves analytical queries and live API calls.

Sub-second point reads

Without a second write path and without forking governance.

35 tables of evidence

The exact failure modes behind retiring Synced Tables, published.

About this white paper

One write authority, two read surfaces

Auraa's foundational principle is that all platform metadata flows through the same Delta-backed medallion as business data. This paper documents the failure modes that led the team to retire Databricks Synced Tables across 35 governance tables, and the GovernanceWriter pattern built to replace it.

Written by the team that built and operates the platform
Includes the trade-offs we accepted, not only the wins

Read the architecture before you build it.

Twenty minutes of reading that can save a migration. No form, no gate, straight to the PDF.

Read the white paper Book a demo

The moment a second database sits alongside Delta Lake, you have two sources of truth, two governance perimeters, and two audit trails. Any sync failure, schema change, or write that reaches one system but not the other fractures the integrity of both. The audit trail forks. Governance policies applied in Delta may not be applied in the secondary database. Auraa's foundational principle is that all platform metadata flows through the same Delta-backed medallion as business data, and that principle cannot coexist with a second write authority.

Auraa deployed Databricks Synced Tables as a sub-second read layer across 35 governance tables in production. The whitepaper documents the exact failure modes encountered at that scale. The team retired Synced Tables and designed the GovernanceWriter pattern as a replacement. The whitepaper publishes the specific failure modes so that other teams can evaluate whether Synced Tables is appropriate for their workload without repeating the same discovery process.

The GovernanceWriter is a single application-layer component that writes to both Delta Lake and Lakebase in one coordinated operation. Delta receives the authoritative write first and remains the only write authority. Lakebase receives a synchronized read-optimized copy of the same governed state. API calls read from Lakebase at sub-second latency. If Lakebase state becomes inconsistent, the GovernanceWriter can rebuild it from the Delta audit trail. There is one write path, one governance perimeter, and one audit trail.

The dual-surface read model means the same governed state in Delta Lake powers two access patterns: analytical workloads via SQL Warehouse for batch processing and reporting, and live API calls via Lakebase for sub-second responses. Because both surfaces draw from the same governed state written by the GovernanceWriter, there is no architectural compromise: the data a SQL Warehouse query sees and the data an API call sees are the same data, governed by the same policies, captured in the same audit trail.

The whitepaper identifies four caveats. Schema discipline: the Delta table and Lakebase must have compatible type systems, and schema changes must be applied to both in coordination. Type-system mapping: not all Delta types map cleanly to operational database types and translation decisions must be made explicitly. Connection pool management: the GovernanceWriter maintains connections to two systems and pool configuration becomes operationally significant at scale. Operating cost: the whitepaper publishes what this approach actually costs to run at Auraa's production scale.