Configurable organization meets the lakehouse

How Tenant-Scoped Delta Paths Enable Single-Source-of-Truth Retrieval

Most multi-tenant platforms bolt isolation on with row-level filters and query interceptors. It holds until one missed filter. Auraa makes isolation a property of how data is addressed.

Read the white paper
Key takeaways

Isolation by addressing

Not by filters. Query the wrong tenant path and you get nothing back.

One write authority

Delta stays the only source. No shadow copy of the truth to reconcile.

Sub-second reads

Lakebase answers API calls without forking the audit trail.

One pipeline everywhere

The same code runs unchanged in dev, staging, and production.

About this white paper

Where addressing Meets governance

Auraa is Covasant's Databricks-native data platform. This paper documents the three foundational design decisions behind its multi-tenant architecture, and how they compound into a system where isolation, consistency, and retrieval performance are structural rather than bolted on.

  • 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
Questions

Questions architects ask us

Row-level filters and query interceptors enforce isolation at read time, not at the storage layer. A missed filter condition in a new query path, or a gap in access-control middleware, exposes data it should not. Auraa's approach treats isolation as a property of how data is addressed and organized from the start. When the wrong tenant path is queried, the result is no data, not the wrong data.
Auraa supports schema-per-project (each project or tenant gets a dedicated schema within a shared catalog), catalog-per-project (each tenant gets a fully isolated catalog with its own Unity Catalog permissions boundary), and environment-catalog (dev, staging, and production exist as separate catalogs). The TenantPathResolver selects and injects the correct strategy at runtime, so pipeline code, quality rules, and agent definitions deploy unchanged across all three environments.
The GovernanceWriter is a single application-layer component that dual-writes to Delta Lake, Lakebase, and the bronze audit trail in one unit of work. Because all three surfaces are updated together, Delta remains the only write authority. API calls read from Lakebase at sub-second latency without introducing a second write path or forking the audit trail. The bronze layer simultaneously receives a permanent, immutable record of every write for governance purposes.
The TenantPathResolver injects the correct environment at runtime. Pipeline code, quality rules, and agent definitions are written once and remain unchanged across environments. When the same pipeline runs in dev, staging, or production, the resolver substitutes the appropriate catalog or schema prefix based on the deployment context. Promotion between environments becomes a configuration change rather than a code change or a separate pipeline to maintain.
The whitepaper identifies three trade-offs. First, path resolver correctness becomes critical infrastructure: a bug in the resolver affects all tenants simultaneously rather than a single misconfigured filter. Second, migrating between isolation strategies (for example, from schema-per-project to catalog-per-project as a client scales) requires data movement and coordination. Third, selective sync decisions require deliberate judgment when not every tenant needs every layer of isolation.