You’re now managing two auth paths for the same database.

The left side of that row comes directly from inside the live Backstage Postgres catalog; the right side comes from a Unity Catalog system billing table. Those two things have historically never been in the same SQL engine, and now they join with zero data movement.

Operationalizing convergence

This three-part series started with a 1-second database branch, moved through unified governance and landed here — a single SQL query that joins operational ownership data to cloud billing data with zero pipelines between them. That's the proof that convergence works technically. The question practitioners will ask next is: what does it take to operationalize this?

Two things stood out from this POC that are worth calling out for teams planning to follow this path.

The federation auth gap

The Lakehouse Federation workaround we described — a native Postgres role with static credentials wired separately from the OAuth identity the app uses — is the right approach today. Every team that wants to join their Lakebase operational data with analytical tables in Unity Catalog will need to set up this parallel auth path. Federation probably shouldn't run as your application user anyway, so the separation has a security upside, but password rotation is on you. For teams adopting this pattern, the steps can be packaged into a repeatable script: generate a secure password, create the role with read-only grants, wire the connection, create the foreign catalog. One-time setup, minutes once you know the pattern. Natively supporting OAuth JWTs in Federation would eliminate this workaround entirely.

Branch cost visibility for dev teams

The FinOps join answers the platform question: what does this infrastructure cost and who owns it? But the same billing data tells a second story that matters to engineering managers: what does the development process itself cost?

In the branching workflow from part one, every pull request creates an ephemeral CI branch and every developer has their own feature branch. These show up as independent line items in system.billing.usage, broken down by branch_id and endpoint_id. An engineering manager can see exactly how much compute their team's dev/test branching consumed in a sprint versus production – and make informed decisions about branch lifecycle policies.

The key is that ephemeral branches should be treated as ephemeral in the billing data too. CI branches created with a short TTL auto-expire if cleanup fails for any reason — a direct push to main, a workflow error, a missed event. Without lifecycle controls, orphaned branches can accumulate quietly, each one with an active compute endpoint billing against the project. The test branch cost 0.0107 DBU. That's trivial. Thirty orphaned branches running for a month are not.

The point isn't that branching is expensive — it's a cost vs productivity gain. When a team eliminates two days of environment wait time per sprint and stops maintaining 20-30% of their codebase in mock objects, the 0.0107 DBU per branch isn't a line item to manage — it's the cheapest productivity investment the team has ever made. And unlike most productivity investments, this one is measurable: the infrastructure tells you exactly what it cost, per branch, per developer, per sprint. That's a conversation most engineering teams have never been able to have with their database.

What comes next

Before we wrap, there's one more point to the FinOps story that should be called out. Lakebase endpoints scale to zero. When a branch isn't being queried, its compute suspends and the bill stops. The 0.0107 DBU figure is the cost of a branch that ran, not the cost of a branch that exists; a fleet of ephemeral branches sitting between test runs contributes nothing.

Across this series, we proved the infrastructure works — real app, real benchmarks, real governance, real cost data. From our side, Databricks and Thoughtworks are working together to take this from POC to practice: real development teams, real sprints, real velocity measurements. The constraint that kept operational and analytical data in separate worlds for thirty years is dissolving.

There's a Monday morning takeaway for every piece of this series:

  • Branch your next migration on a real schema.
  • Rewrite one mock-heavy suite against a branch.
  • Join your billing data to your ownership graph.

The teams that move first will define what comes next.