What will happen if Cloud database becomes too expensive ???

In recent years, moving data to the cloud was the answer to almost every data infrastructure question due to cheap storage, elastic compute, and no need for physical servers. However, over the past 18 months, the data world has witnessed significant changes, and the expenses have caught up with these practices. Many engineering organizations running a modern data stack are now complaining about escalating Snowflake or Databricks invoices. Finance teams are starting to raise concerns in planning meetings.

The initial promise of cloud data platforms was simple: pay for what you use, scale up when busy, and scale down when not. However, in practice, this has not always worked out. Workloads are often left provisioned at peak capacity, auto-suspend settings are ignored, and dashboards refresh more frequently than necessary. The elasticity that was meant to save money turns into a fixed cost that organizations don't revisit.

Moreover, every new dashboard, machine learning feature, or quick transformation job adds more load to a system billed by the second. Although each addition appears insignificant, collectively, it results in a warehouse bill that has tripled in just two years, despite the actual data volume remaining largely unchanged. Many workloads never required distributed compute in the first place, leading to an over-engineered complexity that teams are now paying for every month.

When the cost becomes unsustainable, organizations don't usually abandon the cloud entirely. Instead, they become selective about their cloud usage. The predictable, steady-state workloads such as storage, batch ETL, and standard reporting are easily migrated to cheaper infrastructure or brought back on-premises due to known resource needs. The unpredictable, bursty workloads like ML training or seasonal spikes remain in the cloud, where elasticity truly justifies its premium.

Dropbox and 37signals are examples of companies that successfully repatriated their boring, predictable workloads, saving millions annually. There is also a shift towards right-sized compute, utilizing engines like DuckDB and Polars, which can perform serious analytical work on a single machine instead of spinning up a distributed cluster for data that doesn't require it. This shift emphasizes the need to reject the assumption that everything needs cluster-scale compute by default.

Decoupling storage from compute and treating the compute engine as replaceable is another critical aspect. Open table formats like Iceberg and Delta Lake, stored on plain object storage (S3, GCS, or more affordable alternatives like Cloudflare R2), enable teams to maintain their data in a durable, portable format while allowing flexibility in choosing the compute engine. This approach is a significant structural defense against cost lock-in.

Choosing open formats and vendors that don't penalize users for leaving is crucial. Egress fees and proprietary storage formats contribute significantly to the feeling that cloud costs are irrevocable. Betting on open formats is no longer just a technical preference but a negotiating position. As leaving becomes possible, vendors must compete on price rather than locking customers in.

Fewer companies are opting for multi-cloud for resilience nowadays; instead, they choose multiple cloud providers to ensure vendors remain competitive on pricing.

Overall, this is not an anti-cloud movement but a necessary correction. The industry spent a decade defaulting to maximum scale and maximum vendor convenience. Now, it is learning a lesson every infrastructure generation eventually learns: match the tool to the actual problem size, keep exit options open, and never let "it's just easier this way" become the sole cost strategy.

Companies succeeding in this regard aren't those chasing the cheapest stack. They are those who can explain the costs behind their architecture and have enough options to switch if the costs no longer make sense.