惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Apple Machine Learning Research
Apple Machine Learning Research
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
G
Google Developers Blog
博客园 - 司徒正美
J
Java Code Geeks
aimingoo的专栏
aimingoo的专栏
A
About on SuperTechFans
博客园 - 三生石上(FineUI控件)
WordPress大学
WordPress大学
T
The Blog of Author Tim Ferriss
D
Docker
大猫的无限游戏
大猫的无限游戏
D
DataBreaches.Net
腾讯CDC
V
Visual Studio Blog
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
C
Check Point Blog
M
MIT News - Artificial intelligence
Jina AI
Jina AI
I
InfoQ
雷峰网
雷峰网
The Cloudflare Blog
美团技术团队
Engineering at Meta
Engineering at Meta

Databricks

Why Talent Transformation Is the Missing Focus of Enterprise AI Public Health Intelligence Shouldn't Require a Data Scientist Mean Time to Detect Is a Data Access Problem First-party audience data is the ad sales relationship now Rethinking Distributed Systems for Serverless Performance and Reliability The AI Scaling Gap Hiding in Digital Native Companies 10 trillion samples a day: Scaling beyond traditional monitoring infra at Databricks AI success starts with clean data, not just better models How nOps Rebuilt Their Cloud Optimization Platform on Databricks Lakebase, and Why Other ISVs Should Too Peril Predicts: Precision Payouts for a Volatile World The foundation of AI scalability: one team, one platform, one operating model The Federal Data Paradox: Rich in Data, Poor in Access Driving Budapest Forward: How BKK Uses Databricks to Transform City Mobility LLM Vs AI: A Practical Guide to Differences, Use Cases, and Tools Model Risk Governance Is Not the Same as Risk Intelligence Generative AI for Business: A Complete Strategy and Implementation Guide Data Science vs Data Engineering: Choosing Analysis or Infrastructure AI Applications: Tools, Use Cases, and Platforms MLOps vs DevOps: A Practical Guide for Data Scientists and IT Teams Top Data Warehouse Tools For Modern Data Analytics Unlocking SAP Business Context in Databricks with Semantic Metadata Delta Sharing The marketing activation gap has a fix: Databricks and Stitch partner to turn data infrastructure into marketing performance Alert Fatigue Is a Business Risk Backstage with Lakebase Shipping Faster isn’t Learning Faster Why Your OEE Dashboard Is Lying to You The Turbine That Tried to Tell You It Was Failing Predicting Readmissions Isn't Enough. Acting in Time Is. Clinical Trials Run Longer Than They Have To. That's a Patient Problem Network Quality Is a Revenue Problem, Not a Technical One
Introducing Always-On pricing: automatic savings for Data...
Kunal Kande, Mike Jerome · 2026-05-27 · via Databricks

Most managed operational databases force you into a corner: choose "Serverless" for flexibility but pay a premium, or choose "Provisioned" for a lower unit price but lose agility. That’s a false choice. Today, we’re introducing Always-On pricing for Databricks Lakebase: Serverless flexibility with a predictable, low price for baseline usage. Set your compute scaling parameters and automatically receive a 25% lower price on your baseline capacity.

Why this matters:

  • No Optimization Chores: No more manual rightsizing or long-term use-it-or-lose-it commitments to save costs.
  • Seamless Elasticity: Your database still autoscales to handle spikes; you just pay less for the baseline resources.
  • Total Transparency: One toggle, one low price, zero friction.

Stop spending your evenings and weekends tuning instances. Flip the toggle, keep your performance, and keep more of your budget.

Get the best rates automatically: no long-term contracts required
Get the best rates automatically: no long-term contracts required
Stop paying for idle compute: Legacy Peak Provisioning vs. Lakebase Elasticity
Stop paying for idle compute: Legacy Peak Provisioning vs. Lakebase Elasticity

The tradeoff we’re removing

Postgres products in the cloud have historically forced operators to choose between two options. Legacy provisioned products require payment for peak usage continuously, resulting in oversizing to absorb demand spikes. Serverless products scale elastically, but the per-hour rate is materially higher, making it expensive for workloads that never go idle. Switching between the two meant downtime or maintenance.

Lakebase has already removed several Postgres trade-offs, such as separating storage from compute, pushing full-page writes into the storage layer, and adding instant branching. Always-On pricing innovates the commercial model: the tradeoff between a predictable, lower-cost baseline and elastic compute that absorbs spikes is gone. You don’t pick one architecture for each. You get both on the same database.

How Always-On pricing works

  1. Disable scale-to-zero and set the autoscaling range: On any Lakebase Postgres Autoscaling project, turn off scale-to-zero and set the autoscaling range. The minimum capacity becomes your Always-On baseline, i.e, the compute capacity your database always has available.
  2. Baseline capacity is billed at the lower Always-On rate: After 24 hours of continuous use, your baseline usage is billed at the lower ‘Always-On’ rate. No commitment, no over-provisioning. We automatically bill you at the best rate for your workload.
  3. Autoscale above the minimum at the standard rate: Lakebase will autoscale, up to the maximum capacity set in the autoscaling range, when your database load spikes above the baseline capacity. Usage above the baseline is billed at the regular Autoscaling rates. 

If needed, turn it back on later, and your instance reverts to standard autoscaling pricing.

How this compares to other Postgres options

Most managed PostgreSQL products force a structural choice between a provisioned and a serverless version at provisioning time. To get a better price for your 24/7 workloads, you can either choose a provisioned product and pay for underutilized capacity or make a multi-year, use-it-or-lose-it commitment on a serverless product.  

 

Lakebase

Leading Serverless PostgreSQL products

Leading Provisioned PostgreSQL products 

Lower baseline rate without commitment 

Requires a 1 to 3-year commitment

Provision for peak, not the baseline 

No penalty for changing your baseline

You continue to pay for reservations or a savings plan regardless of the usage 

You pay for underutilized provisioned capacity or deal with downtime to migrate to a smaller provisioned compute instance

Autoscaling for unpredictable peaks on the same instance

What does that buy you in practice?

  • Commitment-free pricing: Automatically get the best price without making long-term commitments or over-provisioning capacity. You can change database configuration and scaling parameters at any time as your requirements change.
  • One unified product: A single offering that scales with your workload, eliminating the upfront choice between 'provisioned' and 'serverless' instances.
  • All qualifying instances, including HA instances, benefit automatically: High Availability replicas and the largest Lakebase instances don’t scale to zero by design. With Always-On, they are now billed at the lower rate without any configuration change.

When to use Always-On and when to keep scale-to-zero

Use Always-On for established baselines. Production workloads whose load history shows a consistent floor of activity with peaks layered on top never benefited from scale-to-zero because the compute never idled. Until today, they had been paying the standard Autoscaling rate for every CU-hour. From today, the baseline portion bills at a 25% lower price, and autoscaling still handles the peaks.

Keep scale-to-zero for new or intermittent workloads. For a new project, you usually don't know. You don't have the load history to set a sensible minimum CU, and the cost of guessing wrong is real: too high and you'll pay for headroom you don't need; too low and autoscaling will spend most of its time above the minimum, defeating the point of the lower rate. This is exactly why scale-to-zero is now the default for new projects. Learn the workload's shape over a few weeks, then make an informed call.

For a workload with an intermittent load, keep scale-to-zero enabled. For a database that's idle 75% of the time, you are much better off paying $0 for those hours. If your autoscaling history shows the compute spending much of its time at zero, leave scale-to-zero enabled.

Ready to stop paying the elasticity tax?

Open your Lakebase project, turn off scale-to-zero, and set a minimum CU that reflects your real baseline. That is the entire configuration change. After 24 hours of continuous use, your baseline capacity is billed at the Always-On rate automatically, and autoscaling remains in place when traffic spikes. No commitment to sign, no new product to provision, no downtime to schedule.

Stack the additional 50% promotional discount running through January 31, 2027, on top, and your Postgres bill just got a lot smaller. Get started with Lakebase today or review the full pricing at https://www.databricks.com/product/pricing/lakebase.