Databricks Lakebase-Branching

In this article we will talk about the Lakebase and what is Lakebase Branching, why it is the most excited feature.

Lakebase is a fully managed, Postgres‑compatible OLTP database that lives natively inside the Databricks Data Intelligence Platform.

Lakebase

In simple terms, it lets you run fast, real‑time transactional workloads right next to your analytics and AI pipelines, without needing to operate or maintain any separate database servers. Everything sits in one unified environment.

⚙️ Lakebase Comes in Two Versions

1. Lakebase Provisioned (Older Generation)

This is the original version of Lakebase.

• You manually choose the compute capacity (provisioned CUs).
• It runs as a traditional instance-based database.
• It includes high availability and point‑in‑time restore via “child instances.”
• It will continue working for existing users, but Databricks will not allow new Provisioned instances after March 12, 2026.

In simple words:
➡️ “You size and manage the compute yourself. Good for existing setups, but no longer the way forward.”

2. Lakebase Autoscaling (Current & Recommended)

This is the latest — and preferred — Lakebase option.

• Compute scales automatically based on actual demand.
• It can scale all the way down to zero when idle (cost saving).
• Supports branching, similar to Git, allowing instant Dev/Test/Feature environments.
• Provides instant restore, making environment resets extremely quick.
• Uses a project‑based architecture instead of fixed database instances.

In simple words:
➡️ “A modern, serverless Postgres that auto‑scales, lets you branch your database like code, and restores instantly. This is the recommended choice for all new workloads.”

Imagine it’s 5:00 PM on a Friday, and everyone ready for the weekend, discussing about their weekend plans

and this happen — The production system for a critical application suddenly starts behaving unpredictably — transactions slowing down, intermittent errors, escalations emails etc.

In any traditional OLTP database, this is where panic starts: people scrambling for backups, trying to replicate the issue in a dev environment, waiting 40–50 minutes for a full restore, running blind in the meantime.

But not for this team.

Instead of guessing, the engineer opens Databricks Lakebase — the fully managed PostgreSQL engine that runs directly inside the Databricks Data Intelligence Platform, powering real-time transactional workloads alongside analytics.

Within seconds, they clicks “Create Branch from Production” — a feature that exists only in Lakebase Autoscaling, the modern offering with autoscaling compute, scale-to-zero, instant restore, and Git‑like branching.

And just like that, a perfect, isolated copy of the production database appears:

Same schema

Same data

Same roles

Same state

But no risk whatsoever to the live system

Remember : If you’re branching from PROD, that branch MUST live only inside a governed, production‑approved UC-controlled project, ensuring:

✅ PII stays inside the allowed boundary

✅ Lineage and audit remain intact

✅ No unauthorised cross-environment exposure

✅ Data residency and security policies stay enforced

The entire investigation took minutes, not hours.

Transactions continue flowing smoothly.

The customers never notice.

And the team avoids a major outage.

This is the moment everyone realizes:

Branching is not a luxury — it’s a new way of working.

Lakebase branching :

Lakebase branching is one of the flagship features of the Lakebase Autoscaling offering — a modern, serverless, fully‑managed OLTP Postgres engine inside the Databricks Data Intelligence Platform.

Branching gives you Git‑like database environments: fast, isolated, copy‑on‑write clones of a production branch, created instantly and with minimal storage.

Lakebase branching

Create branch from Parent instance

Why Branching Exists (Purpose)

Traditional OLTP databases require:

• Full clones (slow & expensive)
• Heavy Dev/Test environments
• Manual restore-from-backup operations

But Lakebase Autoscaling introduces Git‑style branching so teams can:

• Spin up Dev, QA, UAT, Feature, or Hotfix environments instantly
• Experiment safely without touching production
• Restore instantly to previous states
• Support real-time apps, stateful AI agents, and low-latency OLTP workloads all on the same platform

Lakebase Autoscaling

🔧 How Lakebase Branching Works

1. Branches are isolated Postgres environments

A branch is a fully isolated Postgres environment inside a Lakebase Project.

Get Amit Dass’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Each branch has:

• Its own compute
• Its own database schemas
• Its own data state
• Optional read-replicas
• Its own roles & permissions

This is the file hierarchy description:
“Project → Branches → Compute → Roles → Databases → Schemas → Tables / Views”

2. Copy‑on‑write (COW) storage

Instead of copying full data volumes, Lakebase uses copy‑on‑write:

• The new branch points to the same base data blocks as the parent
• Data is only duplicated when changes occur
• Branch creation takes seconds, not minutes/hours
• Storage cost is dramatically lower

This is the same mechanism used by Delta Lake’s “zero-copy clones” but applied to Postgres OLTP.

3. Production branch is “always-on”

By design:

• Production branch has compute running continuously
• Other branches (Dev, QA, feature branches) auto scale to zero when idle
• Compute billing is per-branch, not per-project

4. Each branch has independent compute

Key behaviour:

• Scaling is per branch, not global
• Branches do NOT affect each other
• Heavy testing on a Dev branch will not impact Production
• CPU & RAM expansion occur dynamically

5. Near-instant branch creation & deletion

Teams can create branches for:

• New features
• Bug fixes or hotfixes
• QA regression
• Release candidate testing
• Reproducing production issues

These branches are short‑lived and disposable

🔄 Branching Lifecycle (Step-by-Step)

1. Start from a parent branch (e.g., production)

project: payments_app  
└── branch: main (production)

2. Create a new branch

roject: payments_app  
└── branch: main  
└── branch: feature‑kyc‑rewrite

3. Branch inherits everything from main:

• Schema
• Data
• Roles
• Stored procedures
• Configuration

4. Development/testing happens on the feature branch

• Insert/update/delete data
• Test transactions
• Test schema changes
• Validate logic
  All isolated from Production.

5. Merge or discard

After testing:

• Merge changes into Production (if supported / via migration scripts)
• Or simply delete the branch → instantly freed resources

📌 Benefits of Lakebase Branching

1. Zero-copy Dev/Test environments

No slow restores or data duplication.

2. Instant provisioning

Branches created in seconds.

3. Independent autoscaling

Heavy testing does not affect production capacity.

4. Perfect for AI-driven applications

Lakebase is used for online feature serving, AI agents, and real-time apps requiring sub‑10ms latency. Branching enables safe experimentation for these workloads.

5. Governance through Unity Catalog

Lakebase is fully governed via Unity Catalog:

• RBAC
• Lineage
• Audit
• Schema enforcement

if you found this useful, please connect and share this post so more people can learn about Databricks and data quality.