Lakebase Postgres 成本优化实用指南

Lakebase is a fully managed Postgres database, built for the operational realities of modern application development. What sets it apart from other database vendors in the market also offering a Postgres engine is the architecture underneath, separated storage and compute with a serverless compute layer, and its tight integration with the Lakehouse and the data intelligence platform. You can read more about this architecture and some of the benefits here. A benefit that often flies under the radar, however, is that this architecture also makes Lakebase highly cost efficient. In this blog, we’ll break down where those cost efficiencies come from and share practical tips for getting the most out of them.

How Lakebase is cost-efficient by design

Avoid duplicate storage costs with branching

Database branches allow developers to create isolated environments with production data for development, testing, or experimentation purposes. Unlike approaches that require creating a separate physical copy of the database for each environment, Lakebase branches share the same underlying storage and track changes as the branch diverges from its parent. This makes branching particularly cost-efficient for short-lived development and testing environments, where teams can work with production-like data without needing to provision and maintain a completely separate copy of the database.

Pay only for the compute you use

Autoscaling actively changes the compute resources of your Lakebase instance in response to varying levels of activity. You can control the minimum and maximum range that the instance can scale between. The cost benefits of this feature are clear: compute capacity can scale with workload demand instead of being statically provisioned for peak usage.

Setting a maximum compute size helps make costs predictable because you prevent unexpected spend by capping the upper bound of your compute costs. During moments of low usage, your compute scales down, reducing costs. When coupled with scale to zero, the compute gets suspended entirely after a period of inactivity, reducing compute costs to zero. Compute resumes from scale to zero in a few hundred milliseconds. This makes it especially attractive for scenarios that aren’t exceptionally latency sensitive, such as development workflows, non-production variants of apps, and production apps that don’t need double-digit latencies.

When scale to zero is turned off, Lakebase has always on pricing, which is a 25% discount on your baseline capacity. This cost reduction also applies to any compute that cannot scale to zero, such as HA configurations.

Add replicas and high availability without duplicating storage

Lakebase’s separation of storage and compute also makes read replicas and high availability more cost efficient. Read replicas are independent compute instances that read from the same underlying storage layer as the primary, so scaling read capacity does not require creating and paying for another copy of the database. Similarly, high availability adds redundant compute across availability zones while continuing to use the existing highly available storage layer. This means you can add read scale and compute redundancy without multiplying your storage footprint.

Practical tips for optimizing Lakebase costs

Serve a subset of Lakehouse data with Lakebase Synced Tables

The tight integration of Lakebase with the broader Databricks Intelligence Platform allows for managed syncs between the two environments. Synced tables surface Unity Catalog data in your Lakebase database to support low-latency transactional reads for application or feature-serving use cases.

A common misstep customers make is pushing a large Delta table into Lakebase when the application only queries a much smaller active subset. This inflates Lakebase storage, increases sync costs, and can even lead to performance issues in some scenarios. The fix is simple: sync only the working set needed for the application. Define exactly the data your app needs with a Materialized View, for example a rolling 60-day window, and sync just that. Lakebase sync pipelines can use MV’s automatic change data feed to compute row-level changes at read time. This means changes to the MV, including deletions as rows age out of a rolling window, can be propagated incrementally into Lakebase. The result is a fresh, low-latency active subset in Lakebase while the full history remains in Delta. Pair this with the leanest sync mode that meets your requirements, covered below, and you have a much more cost-efficient reverse ETL pattern.

Using the appropriate Lakehouse → Lakebase sync mode

Synced Tables are managed Serverless Spark Declarative Pipelines (SDP) under the hood and run for the duration of the sync. Consequently, sync cost is driven by factors such as the amount of data being moved and the Lakebase instance size / Capacity Units (CUs).

There are three different sync modes for moving data from the Lakehouse into Lakebase, and it is important to match the mode to how fresh the data truly needs to be. Choosing the right mode allows you to meet your latency requirements while keeping costs under control.

Source: Sync Modes

Snapshot is the most cost-effective option for infrequently updated or highly volatile tables, while Continuous can be the most expensive because its pipeline runs continuously and consumes compute even when there are no changes to process. Snapshot mode is recommended when more than 10% of the source data changes between syncs because it can be up to 10x more efficient. For incremental workloads, Triggered mode offers the ideal balance of cost and latency. You can achieve near-continuous freshness on a budget by pairing Triggered mode with a table-update trigger, ensuring it runs only when source data changes. In general, avoid long intervals between runs, as a massive backlog of changes can make the subsequent sync slow and costly.

Another useful cost optimization is the ability to binpack, or group, multiple tables into a single sync pipeline. If your use case allows for it, the same pipeline can sync changes from multiple Delta tables into Lakebase, allowing those tables to share the same underlying compute. This can be particularly valuable for Continuous syncs, where the pipeline is always running, because it avoids paying for separate continuously running pipelines for each table.

Right-size Lakebase from the start

When a Lakebase project is created, it automatically comes with a production branch and a primary read-write compute. By default, that compute is configured to autoscale between 8 and 16 CU, with scale to zero enabled after 24 hours of inactivity. Those defaults may be perfectly reasonable for your workload, but if your application requires less compute, leaving them unchanged can mean paying for more capacity than you need.

Rather than creating the project and remembering to resize it afterward, you can set the initial compute range when provisioning the project programmatically. For example, using the Databricks SDK:

If you manage Lakebase declaratively with Declarative Automation Bundles (DABs), you can similarly define the compute range for the endpoints you provision:

The single most important input to sizing is your working set: the data and indexes your application accesses frequently, as opposed to the full size of your database on disk. A 2500 GB database with a 20 GB hot working set does not need 2500 GB of RAM. It only needs enough memory to keep those 20 GB, plus some headroom, cached. This matters because of how the compute uses memory. RAM scales linearly with compute size, and up to 75% of a compute’s RAM is available as its compute cache. When your working set fits in that cache, the vast majority of reads are served from memory, so they stay fast and their latency stays consistent. When it does not fit, Postgres has to fetch the pages that miss the cache from storage, which is far slower than a memory hit and introduces the latency variability your application will feel. Sizing is therefore largely the exercise of choosing a compute whose cache exceeds your working set, while also leaving headroom for other operations. Memory is not the only thing that scales with compute size, though. Weigh query complexity, concurrency, and your latency targets too, because a workload that is highly concurrent or sensitive to latency needs more headroom than a lightly used internal tool at the same data size.

Connections to the database also deserve particular attention. max_connections, the hard ceiling on concurrent Postgres connections, is also determined by your compute size, and for an autoscaling compute it follows a specific rule: the limit is set by the smaller of your maximum CU and eight times your minimum CU. Raising the maximum therefore adds connections only up to eight times your minimum, and past that point a small minimum caps how far a larger maximum can take you. An application that opens a large number of connections can hit this ceiling and start rejecting new connections with errors. If connection volume is a real constraint, factor it into your minimum CU, and put a connection pooler in front of Lakebase. A pooler lets many client connections share a pool of Postgres connections and supports up to 10,000 concurrent client connections. Pooling is usually the right answer for apps that open a lot of connections, and it is cheaper than sizing compute up purely to raise the connection ceiling.

You do not have to guess at any of this. The Lakebase Metrics dashboard reports your working set size over 5 minute, 15 minute, and 1 hour windows and shows it directly alongside your available compute cache, so you can see at a glance whether your hot data fits. Read it together with cache hit rate, CPU, RAM, and connection utilization to validate your initial sizing and adjust up or down. For workloads with stable access patterns, comparing the 1 hour working set against available compute cache is a particularly useful signal. Autoscaling delivers the most benefit when your working set already fits in memory at the minimum CU, because otherwise you pay a cold cache penalty every time the compute scales up. Use these metrics to set a minimum that holds your working set and a maximum that absorbs your peaks.

What an undersized compute feels like

Undersizing rarely shows up as an outright failure. More often it appears as symptoms that are easy to misdiagnose:

• Slow and inconsistent query latency. When the working set no longer fits in cache, reads that miss the cache go to storage. Your median latency may still look fine while p95 and p99 climb and become erratic, because performance now depends on whether a given query’s data happened to be cached.
• A falling cache hit ratio. This is the leading indicator that your working set has outgrown available cache, and it starts to slip before latency visibly degrades.
• CPU saturation and query queuing. An undersized compute pegs CPU under load, so queries wait, throughput plateaus, and latency rises across the board.
• Connection errors. Each compute size has a ceiling on concurrent connections; when clients exceed it, new connections are rejected with “too many clients” errors rather than degrading gracefully.
• A cold cache penalty after scaling or waking. After a scale to zero wake, or when autoscaling first scales up, the cache starts empty and has to warm up. You will see a burst of slower queries until the working set is cached again, which is why the minimum compute size matters as much as the maximum.

Optimize your PITR and Snapshot strategy

Point-in-time restore (PITR) continuously maintains the history needed to restore your database to any moment within a configurable recovery window of 2–30 days. Snapshots, on the other hand, are discrete point-in-time captures of a root branch that can be created manually or on an automated daily, weekly, or monthly schedule.

PITR storage grows with both write activity and the length of your recovery window, since Lakebase must retain the history of changes throughout that period. For a write-heavy application, a long PITR window can result in significant storage consumption. A cost-conscious approach is to choose a PITR window that meets your incident-recovery requirements and supplement it with scheduled snapshots when you need longer-term recovery points.

The good news is that both are priced at a lower rate than regular Lakebase branch storage. Snapshot storage ($0.090/GB-month) is roughly 74% cheaper than regular branch storage, while PITR storage ($0.200/GB-month) is about 42% cheaper. Scheduled snapshots can be particularly storage efficient: the first snapshot in a schedule is stored as a full snapshot, while subsequent snapshots are charged only for incremental changes.

Use PITR to recover from unexpected incidents such as accidental deletes or bad writes that could occur at any time within your recovery window. Use snapshots for planned recovery points. For example, take a manual snapshot before a risky migration or bulk update, and use scheduled snapshots for routine, longer-term protection.

Ultimately, match your recovery configuration to your actual recovery requirements. Keeping more history or recovery points than you need can increase storage costs without providing meaningful additional value.

Finding your Lakebase costs

As discussed above, Lakebase costs fall into three areas: database compute, database storage, and, when using Synced Tables, the serverless pipeline compute used to sync data from the Lakehouse into Lakebase.

Compute is metered based on CU usage over time. With Autoscaling, usage follows the compute capacity consumed as the database scales within its configured range.

Storage includes database branch storage, point-in-time restore (PITR) history, and snapshot storage. These are metered separately based on their underlying storage usage.

Synced Tables use managed pipelines to move data from Unity Catalog into Lakebase. The pipeline compute used for the sync is billed separately from the Lakebase database compute.

View Lakebase compute and storage costs

Lakebase compute and storage usage is available in system.billing.usage. Storage usage can be broken down further using product_features.lakebase.storage_type:

• BRANCH_DATA_STORAGE: storage for non-expiring database branches
• BRANCH_CHANGE_STORAGE: changed data stored for expiring branches
• BRANCH_HISTORY_STORAGE: history retained for PITR

The query below joins usage to system.billing.list_prices to estimate daily cost at the effective list price.

Lakebase exposes separate compute and storage SKUs in billing system tables, with the storage type field providing the additional breakdown shown above.

You can find the project UID in the Lakebase UI under Project > Settings > UID. Programmatically, if you know the project name, list projects and match on status.display_name to retrieve its uid.

View Synced Table pipeline costs

Synced Table pipeline usage can also be queried from system.billing.usage. Filter on the underlying pipeline ID and join to system.billing.list_prices to estimate the pipeline's daily cost.

These queries estimate cost using the effective list price for the usage period. Customer-specific contractual discounts are not reflected.

You can find the pipeline ID by opening the Synced Table in the UI and copying Pipeline ID. Programmatically, retrieve the Synced Table and read status.pipeline_id:

Putting it all together

Lakebase is designed to be cost efficient from the architecture up, from shared storage and branching to autoscaling and serverless compute. Pair those built-in efficiencies with thoughtful configuration around sizing, sync strategy, and recovery, and you can keep costs predictable while still getting the performance, availability, and developer experience your applications need.