Databricks Lake base Evolution - Mandatory Shift from Provisioned Instances to Elastic Autoscaling

balajij8 — Fri, 22 May 2026 16:05:50 GMT

The OLTP landscape within the Data Intelligence Platform is undergoing an essential evolutionary step. Databricks has announced an automatic upgrade path shifting all legacy Lake base Provisioned Instances to the modern elastic Lake base Autoscaling architecture commencing June 2026. With the creation of new legacy provisioned capacity databases frozen via the UI and Data API since March 12 2026, organizations must act immediately to plan their migration. It is a fundamental architectural realignment moving workloads from statically provisioned capacity units to a truly elastic, consumption optimized database model improving TCO & ROI.

Architectural Paradigm Shift — Legacy database engines without Autoscaling requires organizations to architect for peak load resulting in expensive over provisioning and idle compute wastage. The modern Autoscaling framework introduces advanced features like Scale-to-Zero, instant database branching and native Lakehouse Sync resulting in excellent cost & performance efficiencies.

Key Milestones

Legacy Freeze: Workspace environments no longer support the creation of legacy Lake base Provisioned instances.
Planned Automatic Upgrade Rollout: Provisioned instances will begin upgrading automatically to the Autoscaling mode starting June 2026. Plan for a migration proactively ahead of time to ensure an ideal upgrade based on the workloads.
Impact: The technical & cost advantages of shifting away from rigid capacity units are immense but watch out for compute model, storage, networking, API and restore window variances to plan an ideal upgrade

Feature Comparison

Feature	Lake base Provisioned (Legacy)	Lake base Autoscaling (Modern)
Compute	Manual sizing allocation via rigid Provisioned Capacity Units	Dynamic sizing via Autoscaling Compute Units (Range / Fixed CU)
Scaling Telemetry	Basic resource mapping	Advanced Tracking - CPU load, Memory usage & Working Set Size
Compute Density	1 Capacity Unit = 16 GB RAM	1 Compute Unit (CU) = 2 GB RAM (8x scaling granularity)
Idle Expenses	Continuous flat billing	Scale-to-zero drops compute cost to $0 during periods of inactivity (24 hr inactivity for automatically migrated instances but can be changed later)
Endpoint Hostname	Global format	Regional format
Data Restore Lifecycle	Up to 35 days	Up to 30 days for instant restore, time travel & branching
Database Engine	Legacy PostgreSQL 16 alignment	Recent PostgreSQL 17
Networking	Standard Front-end Private Link (Workspace-level)	Front End Link for API (workspace level connectivity) Inbound Private Link for performance intensive services
Data Sync Topology	Synced Tables - Forward ETL to serve Lakehouse data with Lake base	Lakehouse Sync - Native sync to Delta/Iceberg tables

Automatic Upgrade Mapping

The Database Instance API automatically maps legacy Provisioned capacities to new elastic Autoscaling ranges in the Automatic Upgrade rollout.

Legacy Provisioned	Modern Autoscaling
1 Capacity Unit (16GB RAM)	Compute Unit - Min 4 / Max 8 (8GB to 16GB RAM elastic boundary).
2 Capacity Units (32GB RAM)	Compute Unit - Min 8 / Max 16 (16GB to 32GB RAM elastic boundary).
4 Capacity Units (64GB RAM)	Compute Unit - Min 16 / Max 32 (32GB to 64GB RAM elastic boundary).
8 Capacity Units (128GB RAM)	Compute Unit - Fixed 64 (128 GB)

Critical Guardrails

Autoscaling mode is supported for computes up to 64 CU (128 GB). Heavy weight operational workloads requiring scale beyond this threshold must leverage Larger fixed size computes of 80 - 112 CU (static compute allocations). Please note the strict maximum ceiling for dynamic scaling. The introduction of regional hostnames and specialized inbound Private Links requires organizations to review network routes before the planned rollout. Automatically migrated instances default to a 24-hour inactivity timeout before shutting down compute. While conservative and safe for production cases, organizations should actively adjust the window down in lower environments to instantly slash compute costs.

Configuration Topologies - Workloads can be assigned to one of three blueprints based on the operational characteristics

Fixed size - A static compute type ranging from 0.5 – 64 CU. Its best suited for predictable, continuous services that demand static resource predictability.
Autoscaling - The elastic compute tier ranging from 0.5 – 64 CU. The database monitors live memory constraints and working set sizes to intelligently scale up or down within the minimum/maximum configuration boundaries.
Larger Fixed size – High performance fixed brackets engineered for very large-scale setups ranging from 80 - 112 CU (224 GB). This compute type does not support autoscaling

The Lake base transition offers a architectural leverage point - it completely eliminates the operational debt of capacity management. By proactively auditing networking topologies and tuning Autoscaling Compute Unit limits, organizations can achieve excellent query performance during peak traffic windows while driving infrastructure costs down to zero during off hours and unlock up to 70%+ cost savings.

topic Databricks Lake base Evolution - Mandatory Shift from Provisioned Instances to Elastic Autoscaling in Lakebase Articles

Databricks Lake base Evolution - Mandatory Shift from Provisioned Instances to Elastic Autoscaling