Autoscaling by default
Starting March 12, 2026, new Lakebase instances will be created as Lakebase Autoscaling projects (instead of Provisioned instances) so you can use capabilities such as autoscaling compute, scale-to-zero, branching, and instant restore.
The rollout begins on March 12 and is expected to complete within a few days. Until your workspace is updated, you can still create Provisioned instances. Once your workspace is in the rollout, any new Lakebase instance you create will be an Autoscaling project.
When you create a new Lakebase instance, it is now created as a Lakebase Autoscaling project and appears on the Autoscaling page in the Lakebase app, not on the Provisioned page. Existing Provisioned instances are not affected and continue running exactly as before.
On the Autoscaling page, the new projects are marked with an information icon.
Hover over the icon and you'll see a tooltip explaining that the project was created using the Database instance API, and that it supports both Database instance and Postgres APIs.
What this means for you
- Lakebase instance creation. Any new Lakebase instance is created as a Lakebase Autoscaling project and appears on the Autoscaling page in the Lakebase app. You can manage these projects with both the Database instance API and the Postgres API.
- Create button in the UI. The Create button (including in the Provisioned tab) now opens the Autoscaling project creation flow.
- Autoscaling features. New projects get autoscaling compute, scale-to-zero (disabled by default to match Provisioned behavior), branching, and instant restore. You can access these features from the Lakebase Autoscaling UI and Postgres API when you're ready.
- Existing Lakebase Provisioned instances are unchanged. They stay on the Provisioned page in the UI with the same behavior as before. Existing Provisioned instances keep running, connection strings keep working, and APIs remain operational.
- Your existing automation continues to work. Your existing automation keeps working without modification, but new instances are created as Autoscaling projects.
At a future date, you will be able to upgrade Provisioned instances to Lakebase Autoscaling projects. Databricks will communicate the upgrade timeline as it approaches.
APIs
To ensure your existing automation developed on Lakebase Provisioned continues to operate without interruption, both the Database Instance API (Lakebase Provisioned) and the Postgres API (Lakebase Autoscaling) work with newly created Lakebase instances. The following table shows which API to use, depending on how your project or instance was created.
How the project or instance was created | API to use |
|---|---|
New projects created using the Database instance API or the Lakehouse/Provisioned UI | Both the Database instance API and the Postgres API work. You can manage the same project with either API. |
New and existing projects created only in the Autoscaling UI or with the Postgres API | Postgres API only. |
Existing Lakebase Provisioned database instances | Database instance API only. |
If you use the Feature Store or sync tables and provision them programmatically (for example, online feature stores), use the Database instance API for now. Programmatic provisioning of sync tables is not yet supported on the Postgres API. This gap will close in a future release.
Lakebase API support will eventually converge on the Postgres API. Databricks will communicate the timeline for moving away from the Database instance API as it approaches.
Differences for new Lakebase instances
If you're used to Lakebase Provisioned, new Lakebase instances created as Lakebase Autoscaling projects have some special characteristics. Here's what to expect.
Compute size
Lakebase instances created as Autoscaling projects use Autoscaling compute units (CUs) instead of Lakebase Provisioned capacity units. When a project is created using the Database instance API, your chosen Lakebase Provisioned capacity unit is mapped to a Lakebase Autoscaling min and max autoscaling CU range as follows:
RAM per unit: In Lakebase Provisioned, one capacity unit has 16 GB RAM. In Lakebase Autoscaling, one CU has 2 GB RAM.
Provisioned capacity | Autoscaling min CU | Autoscaling max CU |
|---|---|---|
1 (16 GB) | 4 (8 GB) | 8 (16 GB) |
2 (32 GB) | 8 (16 GB) | 16 (32 GB) |
4 (64 GB) | 16 (32 GB) | 32 (64 GB) |
8 (128 GB) | 64 (128 GB) | 64 (128 GB) |
Lakebase Autoscaling supports autoscaling only up to 32 CU. Larger sizes (including 64 CU) are fixed-size. So for capacity 1-4, you get a min-max autoscaling range. For capacity 8, you get a fixed 64 CU compute (min and max both 64).
For example, if your automation creates Lakebase instances with capacity 1, new Lakebase Autoscaling projects are created with min CU 4 and max CU 8 settings. You can change min/max later using the Postgres API or in the Lakebase Autoscaling UI. If you set max CU above 64 using the Postgres API, the Database instance API will report capacity as 8.
All new instances, including those created using the Database instance API, run on the Autoscaling platform and use Lakebase Autoscaling pricing. See the Lakebase pricing page for details.
Existing Provisioned instances remain on their current pricing until they are upgraded to Autoscaling. Databricks will communicate the upgrade timeline as it approaches.
Scale-to-zero
The read/write endpoint for new projects has scale-to-zero disabled by default, so compute is always running, same as on Lakebase Provisioned instances. No change in behavior. When enabled, scale-to-zero suspends your compute after a period of inactivity (default 5 minutes, minimum 60 seconds), so you pay only for active compute time. You can enable scale-to-zero in the Lakebase Autoscaling UI or using the Postgres API. See Scale to zero for details.
Instant restore (restore window)
On Lakebase Provisioned (database instances), the restore window can be set up to 35 days. On Lakebase Autoscaling (new projects), the instant restore setting has a maximum of 30 days. If you rely on a restore window longer than 30 days on Provisioned, note that new projects support a maximum of 30 days for point-in-time recovery, time travel, and branching from past states.
PostgreSQL version
New projects created through the Database instance API or Lakehouse/Provisioned UI use PostgreSQL 16, aligned with Lakebase Provisioned. That means automation using the Database instance API creates projects with the same PostgreSQL version (16) as before. The default for projects created using the Autoscaling UI or Postgres API is PostgreSQL 17.
Connection details and hostnames
Connection details for new projects use a different hostname format than Lakebase Provisioned. Provisioned instances use a global hostname (no region in the hostname). Newly created projects use a regional hostname (region included). Both read-write and read-only endpoints use the regional hostname format for new projects.
Provisioned (global hostname):
host=instance-a1b2c3d4-e5f6-7890-abcd-ef1234567890.database.cloud.databricks.com
Autoscaling (regional hostname):
host=ep-example-endpoint-a1b2c3d4.database.<region>.cloud.databricks.com
The regional hostname includes the region code for your cloud and region (for example, us-east-1 on AWS or eastus on Azure).
If you use IP allowlists, you must allow the regional ingress IPs for your region for new projects. See Create IP access lists for workspaces.
Private Link
Lakebase Autoscaling uses two Private Link endpoints: front-end Private Link for API access (workspace-level connectivity. Most customers already have this, no change) and Service Direct Private Link (also called regional front-end Private Link) for connecting Postgres clients to the database. Service Direct Private Link is in Public Preview. If you use Private Link and create a new Lakebase instance, you only need to add Service Direct if you do not already have it. Front-end Private Link is unchanged. Existing Provisioned instances keep their current Private Link configuration.
Your situation | What you need |
|---|---|
You use Private Link and create a new instance, and you do not yet have Service Direct Private Link | |
You already use Lakebase Autoscaling or other services that use Service Direct Private Link | No change. |
You only use existing Provisioned instances and do not create new ones | No change. |
Permissions (ACLs)
For projects created from the Lakehouse/Provisioned UI or the Database instance API, two separate sets of ACLs apply: database instance ACLs and Lakebase project ACLs. Each set is managed independently, so a user can have different effective access depending on which API is used.
- Database instance ACLs: Set using the Database instance API. Evaluated when you call the Database instance API.
- Lakebase project ACLs: Set using the Lakebase Autoscaling UI or the Postgres API. Evaluated when you use the Postgres API or the Autoscaling UI.
Both ACL sets apply to new projects created using the Database instance API or Lakehouse/Provisioned UI. Review both Database instance and Lakebase project ACL sets to understand the default permissions granted to workspace members. Default permissions on new projects can be broader than on Lakebase Provisioned, reflecting the wider set of capabilities in Lakebase Autoscaling.
Project names and instance names
Project and instance names must be DNS compliant. Name uniqueness is case insensitive, which means you cannot have both ABC and abc in the same workspace. When using the Postgres API, use the lowercase project name. Creation fails if the name collides with an existing project ID.
Branch and project rename
For projects created using the Database instance API or the Lakehouse/Provisioned UI, branch rename and project rename are not available. The name you use in the Database instance API is the name of the project and branch in the Autoscaling UI.
Child database instances
For child database instances (a child instance corresponds to a branch on the Autoscaling project):
- Branch limit. With the Postgres API or the Autoscaling UI, you can create any number of branches. With the Database instance API, you can create only one parent instance (one root branch) and one child instance (one child branch), which matches the previous Database instance API behavior.
- Tags and budget. Custom tags and budget policies are inherited from the parent branch. This is a change from the previous Database instance API behavior, where child instances had their own separate values.
- Deleting a child instance. If you create additional branches using the Lakebase Autoscaling UI or Postgres API on a project that corresponds to a child instance, you cannot delete that child instance through the Lakehouse/Provisioned UI or API until all of those branches are deleted. Delete the branches first (using the Autoscaling UI or Postgres API), then delete the child instance.
Protected branches
If you protect a branch on a project created using the Database instance API (whether the branch corresponds to a child instance or any other branch you created), you cannot delete that child instance or the root (parent) instance through the Lakehouse/Provisioned UI or API until the branch is unprotected. Unprotect the branch in the Lakebase Autoscaling UI first, then delete the instance. See Protected branches.
Private preview features
Newly created projects are Lakebase Autoscaling projects and do not support the Lakebase Provisioned Data API or Forward ETL private preview features. Those were separate offerings on Provisioned.
- REST API access (PostgREST-style): Lakebase Autoscaling has its own Data API for PostgREST-compatible REST access (CRUD, query, RPC).
- Syncing data to the lakehouse: Lakebase Autoscaling has Lakehouse sync, which is different from the private preview Forward ETL on Lakebase Provisioned.
Frequently asked questions (FAQ) about Autoscaling by default
Does this apply to both AWS and Azure?
Yes. The change applies to both AWS and Azure. The rollout begins on the same date on both clouds.
Where do newly created Lakebase instances appear?
On the Autoscaling page in the Lakebase app, not on the Provisioned page. See the intro above.
What happens when I click Create in the Lakebase UI?
The Create button (including in the Provisioned tab) opens the Autoscaling project creation flow. You can no longer create new Provisioned instances from the UI. If you have no Provisioned instances, the Provisioned tab is hidden. See What this means for you.
Are all features that were available on Provisioned also supported on Autoscaling?
Most capabilities available on Lakebase Provisioned are supported on Lakebase Autoscaling, with some differences. For a full side-by-side comparison, see the Feature comparison table on the Lakebase index page.
What does NOT change?
The following are unchanged:
- Existing Provisioned instances: they keep running with their current connection strings, pricing, and Private Link configuration.
- Existing Autoscaling instances: no change.
- The Database instance API: it remains fully supported. You do not need to change existing Terraform, SDKs, or other automation that you developed for Lakebase Provisioned.
- Connection strings for existing Lakebase Provisioned instances: they remain unchanged. No updates required.
- Private Link configuration for existing Provisioned or Autoscaling instances. No change.
How does this change impact pricing?
All new instances (including those created using the Database instance API) use Lakebase Autoscaling pricing. See Compute size.
Can I still use the Database instance API for new projects?
Yes, for new projects created using the Database instance API or Lakehouse/Provisioned UI. Both APIs work for these newly created projects. See APIs.
Can I use the Postgres API for my existing Provisioned instances?
No. Use the Database instance API only for existing Lakebase Provisioned instances. See APIs.
Can I enable scale-to-zero or set min/max CU with the Database instance API?
No. New projects created with the Database instance API have scale-to-zero disabled by default. To enable scale-to-zero or set the autoscaling compute range (min/max CU), use the Postgres API or the Lakebase Autoscaling UI. The Database instance API does not expose these controls. See Compute size and Scale-to-zero.
Why do the capacity numbers look different (for example, capacity 1 vs 4-8 CU)?
Autoscaling uses compute units (CUs) with a different RAM-per-unit than Provisioned capacity. See Compute size.
What PostgreSQL version do new projects use?
Projects created from the Lakehouse/Provisioned UI or the Database instance API use PostgreSQL 16, same as Lakebase Provisioned. Automation using the Database instance API therefore gets the same PostgreSQL version (16) as before. See PostgreSQL version.
Do I need to change my connection details or hostnames?
New projects use regional hostnames. If you use IP allowlists or Private Link, you need to update them for newly created projects. See Connection details and hostnames.
Do I need to change my Private Link setup for new instances?
Most customers do not need to change anything. You only need to add Service Direct Private Link if you use Private Link, create new Lakebase instances, and do not already have Service Direct Private Link configured. If you already use Lakebase Autoscaling or other services that use Service Direct, or you only use existing Provisioned instances, no change is needed. See Private Link for the full table and setup links.
Do my existing Provisioned instances need any Private Link changes?
No. Existing Provisioned instances keep their current Private Link configuration. No reconfiguration is required. See Private Link.
What's the difference between the restore window (Provisioned) and instant restore (Autoscaling)?
Lakebase Provisioned supports a restore window of up to 35 days. New Lakebase Autoscaling projects use instant restore with a maximum of 30 days. See Instant restore (restore window).
How do instance and project names work for new Lakebase instances?
Names must be DNS compliant. Uniqueness is case insensitive (you cannot have both ABC and abc). When using the Postgres API, use the lowercase project name. Creation fails if the name collides with an existing project ID. See Project names and instance names.
Do my existing Provisioned instances change?
No. They stay on the Provisioned page with the same behavior. Only new Lakebase instances are created as Autoscaling projects.
How do permissions work on projects created from the Lakehouse/Provisioned UI or Database instance API?
For those projects, two separate ACL sets (database instance and Lakebase project) apply, and default permissions can be broader than on Lakebase Provisioned. Check both sets if you need to restrict access. See Permissions (ACLs).
Can I use PostgREST or get REST API access to my new project?
The Data API (PostgREST-style) was a private preview feature on Lakebase Provisioned. Newly created projects use the Lakebase Autoscaling Data API for PostgREST-compatible REST access (CRUD, query, RPC). See Private preview features.