Introducing Databricks Lakebase

Lakebase is Databricks’ fully managed PostgreSQL database. It lives inside your Databricks workspace with same authentication, same governance, same platform you already use for analytics and AI.

Think of it as your operational database and your data platform, unified.

Two versions are available:

• Lakebase Autoscaling — scales up and down automatically, scales to zero when idle, supports branching (instant copy-on-write clones for safe testing), point-in-time restore .
• Lakebase Provisioned — fixed compute you manually scale

Demo Time

Airport Operations Center

I built a full airport operations smart application . Here’s what’s running -

Data: 8 Postgres tables — flights, passengers, baggage, gates, security alerts, staff, and two prediction tables written by Databricks ML jobs.

Live simulator: A Databricks serverless job that ticks every 60 seconds and simulates real airport activity — flights moving from SCHEDULED → BOARDING → DEPARTED, passengers checking in, baggage scanning through 6 checkpoints, security alerts appearing and resolving.

ML jobs: Two more serverless jobs run on a schedule — one scores flight delay risk using a gradient boosted model, one predicts gate congestion. Both write predictions back to Lakebase tables. The dashboard reads them like any other table.

The app: A dashboard deployed as a Databricks App, connected to Lakebase

Auto-refreshes every 30 seconds.

Views

Operations Overview

KPI cards at the top: total flights, on-time %, average delay, active security alerts, bags at risk, passengers checked in. Live flight board below.

AI Predictions

Flight delay risk table — HIGH / MEDIUM / LOW color-coded, with predicted delay minutes and confidence score. Gate congestion predictions below.

Baggage Intelligence

All bags currently flagged as at-risk (scan gap exceeded threshold). Scan event timeline per bag.

Gate Operations

Gate congestion status across all terminals. Staff count per terminal.

Unity Catalog

Row-Level Security and Masking on Operational Data

This is where it gets interesting. The airport hosts flights from multiple airlines. Saudia staff should only see Saudia flights. Emirates staff should only see Emirates flights. Airport admin sees everything.

One SQL function in Unity Catalog and apply to the table

CREATE FUNCTION kanika_demos.smart_airport.flights_airline_filter(airline_code STRING)

RETURN IS_MEMBER(‘airport_admin’)

OR IS_MEMBER(‘airlinestaff’ || lower(airline_code));

Now the filter is enforced at query time — regardless of tool, app, or user. No WHERE clauses in application code. No per-role views to maintain. Remove a user from the airport_admin group and they instantly lose access to the rows they shouldn’t see.

Same approach for PII masking : passport numbers, national IDs, and phone numbers are masked for anyone outside the security team at the column level in Unity Catalog.

Conclusion

What used to require separate systems , an operational database, an analytics platform, an ML serving layer, a governance tool — now runs on one platform.

The Lakebase instance, the prediction jobs, the dashboard app, the row-level security all live in the same Databricks workspace.

That means one authentication system, one access control model, one place to see lineage and audit logs, no custom codes in between and your compelte Data Intelligent platform is ready .