AI 服務暫時不可用，以下為來源正文，待恢復後補全翻譯。
A practical guide to cost optimization with Lakebase Postgres | Databricks Blog Skip to main content Lakebase is cost-efficient by design because its separated storage and compute architecture lets branching, read replicas, and high availability share one storage layer, while serverless autoscaling and scale-to-zero mean you pay only for the compute you actually use. The biggest practical savings come from syncing only the working subset of Lakehouse data into Lakebase, matching your sync mode (Snapshot, Triggered, or Continuous) to how fresh the data truly needs to be, and right-sizing compute so your hot working set fits in cache. Applying these practices, syncing just the working set, matching sync mode to freshness needs, right-sizing compute so hot data fits in cache, and tuning PITR and snapshots, keeps costs predictable and low without giving up the performance, availability, and developer experience your applications need. 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. ModeDescriptionBest to use when SnapshotCopy of all dataSource changes >10% of rows per cycle. Will be substantially more cost-effective than Triggered in those scenarios. TriggeredIncremental updates that run on demand or at intervalsSource rows change on a known cadence. Inserts, updates, and deletes are propagated each refresh. ContinuousReal-time streaming with seconds of latencyChanges must appear in Lakebase in near real time. This provides the lowest lag at the highest cost. 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 i [truncated for AI cost control]