Lakebase Autoscaling pricing
This feature is in Public Preview in the following regions: us-east-1, us-west-2, eu-west-1.
Lakebase Autoscaling is the new version of Lakebase with autoscaling compute, scale-to-zero, branching, and instant restore. For feature comparison with Lakebase Provisioned, see choosing between versions.
To allow users to explore the new version of Lakebase, usage of Lakebase Autoscaling is free for a limited time.
Billing for Lakebase Autoscaling usage begins in January 2026. The prices listed below are indicative of the Lakebase Autoscaling Enterprise Tier in AWS US East (N. Virginia). Final pricing will be released prior to the billing start date. Prices are subject to change and may vary by cloud and geographical region.
Pricing summary
Lakebase Autoscaling pricing is based on your actual resource consumption across four categories:
Resource | Price | Unit |
|---|---|---|
Compute | $0.111 | CU-hour |
Database storage | $0.35 | GB-month |
Instant restore (PITR) storage | $0.20 | GB-month |
Branch snapshot storage | $0.09 | GB-month |
Compute
$0.111 per CU-hour
Compute usage is billed in CU-hours, which represents one Compute Unit running for one hour. Each CU allocates approximately 2 GB of RAM, along with appropriate CPU and local SSD resources.
How you're charged:
- You're charged for the time your compute is active and processing workloads.
- With autoscaling, you're billed for the actual CU size used as your compute scales between minimum and maximum limits to meet demand.
- When a compute scales to zero during inactivity, you aren't charged for compute time while it's suspended.
Example: A 10 CU instance (20 GB RAM) running continuously for 30 minutes consumes 5 CU-hours, which costs $0.56.
See Manage computes, Autoscaling, and Scale to zero.
Database storage
$0.35 per GB-month
Database storage is billed based on your data size, measured hourly. How storage is measured depends on whether your branch has an automatic expiration set:
- Non-expiring branches: Measured using actual data size (logical data size).
- Expiring branches: Measured using the size of all data changes (the log of INSERT, UPDATE, and DELETE operations) since branch creation or the logical data size, whichever is lower. This optimized billing ensures temporary branches are cost-effective.
About branch expiration:
When creating a branch, you can set an automatic deletion by checking Automatically delete branch after (enabled by default with a 1-day expiration). Non-expiring branches persist until manually deleted. Expiring branches automatically delete after a specified time (up to 30 days) and are ideal for temporary environments like CI/CD pipelines, automated testing, and feature development.
Examples:
- Expiring branch: If you create an expiring development branch from a 100 GB production branch and add 100 GB of data, you're billed for only 100 GB. This is the lower of the two values: 100 GB (size of data changes) vs 200 GB (logical data size).
- Non-expiring branch: If you create a non-expiring development branch from a 100 GB production branch, you're billed for 100 GB (the logical data size of the branch). If these are the only two branches in your project, your total storage billing is now 200 GB.
See Branches and Branch expiration.
Instant restore (PITR) storage
$0.20 per GB-month
Instant restore (PITR) storage is billed based on the volume of data changes retained within your configured restore window (up to 30 days). You can set your restore window in your project settings, with the default being 1 day.
How you're charged:
- PITR storage is the size of all data changes (the log of INSERT, UPDATE, and DELETE operations) during your selected restore window, measured hourly.
- You're charged for the volume of data changes, not the number of restore operations performed.
- Longer restore windows retain more historical data changes, resulting in higher storage costs.
- All branches in your project share the same restore window setting.
See Point-in-time restore and Configure your restore window.
Branch snapshot storage
$0.09 per GB-month
Branch snapshot storage is billed based on the actual size of your snapshot data. Snapshots are read-only backups that capture the complete state of a branch at a specific point in time.
How you're charged:
- Each snapshot stores the full state of your branch at the time it was created.
- Storage is measured by the actual data size (logical data size) of each snapshot.
- Snapshots are independent copies, so multiple snapshots increase storage costs proportionally.
- Automated snapshot schedules with retention policies help manage storage costs by automatically deleting old snapshots.
See Snapshots and Create a backup schedule.
Cost optimization
You can optimize Lakebase costs by configuring resources to match your actual usage patterns:
Compute costs:
- Enable autoscaling: Configure minimum and maximum CU limits to automatically scale compute resources based on workload demand, ensuring you only pay for the resources you need.
- Enable scale to zero: Allow computes to automatically suspend during periods of inactivity, eliminating compute charges when workloads aren't running. This is ideal for non-production branches used for testing, staging, or development.
- Right-size your compute: Set appropriate minimum CU values based on your baseline workload requirements to avoid over-provisioning.
Database storage costs:
- Use expiring branches for temporary work: Set automatic expiration on branches used for CI/CD pipelines, testing, and feature development to reduce storage costs. Expiring branches are billed only for data changes rather than full logical data size.
- Clean up unused branches: Regularly review and delete non-expiring branches that are no longer needed, as each non-expiring branch adds to your total storage billing.
Instant restore (PITR) storage costs:
- Adjust your restore window: Set your project's instant restore window based on your actual recovery requirements. Shorter windows (1-7 days) retain less historical data and cost less than longer windows (up to 30 days).
Snapshot storage costs:
- Configure retention policies: Set up automated snapshot schedules with appropriate retention periods to automatically delete old snapshots and prevent storage accumulation.
- Delete unnecessary snapshots: Regularly review and remove manual snapshots that are no longer needed for compliance or recovery purposes.
- Balance backup frequency with retention: Consider whether you need daily snapshots retained for 30 days or if weekly snapshots with shorter retention would meet your needs.
See Manage computes, Autoscaling, Scale to zero, Branch expiration, Configure your restore window, and Create a backup schedule.