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.
