DEV Community: KingUSD

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

KingUSD — Mon, 24 Aug 2026 04:20:50 +0000

For most of the last fifteen years, "move it to the cloud" was the answer to almost every data infrastructure question. Storage was cheap, compute was elastic, and nobody had to rack a server again. But for the past 18 months, a lot has happened to the data world — and the bills caught up with them.
Walk into almost any engineering org running a modern data stack today and you'll hear some version of the same complaint: the Snowflake or Databricks invoice keeps climbing, nobody can fully explain why, and finance is starting to ask uncomfortable questions in planning meetings. This isn't a hypothetical problem anymore. It's the reason "cloud repatriation" has gone from a niche blog post topic to a boardroom conversation.

How we got there

The pitch behind cloud data platforms was simple: pay for what you use, scale up when you're busy, scale down when you're not. In practice, a few things went wrong.
Nobody scales down. Warehouses get provisioned for peak load and then just... stay there. Auto-suspend settings get ignored. Dashboards refresh every five minutes when once a day would do. The elasticity that was supposed to save money quietly turns into a fixed cost nobody revisits.
Compute and complexity crept up together. Every new dashboard, every new ML feature, every "quick" transformation job adds a little more load to a system billed by the second. Individually, none of it looks expensive. Collectively, it's a warehouse bill that's tripled in two years while the actual data volume barely changed.
A lot of workloads never needed distributed compute in the first place. Teams reached for Spark clusters and enterprise warehouses on datasets that would fit comfortably on a laptop. The industry over-engineered itself into complexity it didn't need, and now it's paying rent on that complexity every month.
Egress and lock-in quietly tax the exit. Once your data lives in a vendor's proprietary format, leaving isn't just a technical migration — it's a bill in itself. That friction keeps teams paying prices they'd otherwise walk away from.

What Happens When It Gets Too Expensive

When the cost curve stops making sense, teams don't usually abandon the cloud wholesale — they get selective about it. A few patterns are showing up consistently across the industry right now.

Repatriation of the boring, predictable stuff.
The workloads that run the same way every day — steady-state storage, routine batch ETL, standard reporting — are the easiest to move to cheaper infrastructure or bring back on-prem, because their resource needs are known in advance. The unpredictable, bursty workloads (ML training, seasonal spikes) stay in the cloud, where elasticity actually earns its premium. Dropbox and 37signals both made headlines doing exactly this and saving millions annually.
A shift toward "right-sized" compute.
This is the rise of tools like DuckDB and Polars: engines built to do serious analytical work on a single machine instead of spinning up a distributed cluster for data that never needed one. If your dataset fits in memory on a beefy laptop, you don't need to pay for a warehouse cluster to query it. It's less about rejecting the cloud and more about rejecting the assumption that everything needs cluster-scale compute by default.
Decoupling storage from compute — and taking it seriously.
Open table formats like Iceberg and Delta Lake, sitting on plain object storage (S3, GCS, or increasingly cheaper alternatives like Cloudflare R2), let teams keep their data in a durable, portable format while treating the compute engine as replaceable. Snowflake today, DuckDB or Trino tomorrow — same data, no re-platforming project required. This is arguably the single biggest structural defense against cost lock-in.
Choosing formats and vendors that don't punish you for leaving.
Egress fees and proprietary storage formats are a large part of why cloud costs feel inescapable. Betting on open formats isn't just a technical preference anymore — it's a negotiating position. When leaving is actually possible, vendors have to compete on price rather than lock-in.
Multi-cloud as leverage, not ideology.
Fewer companies are going multi-cloud for resilience these days and more are doing it because having a second viable vendor is the only thing that keeps the first one honest on pricing.

The Underlying Shift
None of this is really an anti-cloud movement. It's a correction. The industry spent a decade defaulting to maximum scale and maximum vendor convenience, and it's now relearning a lesson every infrastructure generation eventually learns: match the tool to the actual size of the problem, keep your exits open, and never let "it's just easier this way" become the whole cost strategy.
The teams handling this well aren't the ones chasing the cheapest possible stack. They're the ones who can actually answer the question "why does this cost what it costs?" — and who've built enough optionality into their architecture that if the answer ever stops making sense, they have somewhere else to go.

SSH Explained...

KingUSD — Thu, 20 Aug 2026 17:32:45 +0000

SSH stands for Secure Shell, a network protocol that allows someone to securely connect to and communicate with a remote machine over an unsecured network. Before SSH existed, tools like Telnet existed, but anyone could snoop the network and SSH fixed that by encripting the entire session.

The main parts of SSH

Transport Layer — Handles the initial connection, server authentication, and encryption setup. This is where the client confirms it's talking to the right server and both sides agree on an encryption algorithm to protect everything that follows.
Authentication Layer — Confirms who is connecting. This is where passwords or, more commonly, key pairs come in.
Connection Layer — Once you're authenticated, this layer manages the actual session: running commands, forwarding ports, transferring files, all multiplexed over the single encrypted connection.

How SSH authentication works

The most common and most secure way to authenticate with SSH is public key authentication, and it's worth understanding the flow rather than just trusting it works:

You generate a key pair on your machine (ssh-keygen). This produces two files: a private key and a public key.
You give the public key to the server or service you want to access — for example, pasting it into GitHub's SSH key settings, or appending it to ~/.ssh/authorized_keys on a remote server.
When you connect, the server sends a cryptographic challenge that can only be answered correctly by whoever holds the matching private key.
Your SSH client uses your private key to respond to that challenge — without ever sending the private key itself over the network.
If the response checks out, the server knows you hold the private key, and grants access.

This is the important part: your private key never leaves your machine, even during authentication. That's fundamentally different from a password, which has to be transmitted (even if encrypted) for the server to check it.

You can also authenticate with a password over SSH, but key-based authentication is standard practice because it's far more resistant to brute-force attacks and doesn't rely on you (or a service) remembering and protecting a secret string.

SSH vs HTTPS

HTTPS is the protocol most people are already familiar with from browsing the web. When used with Git, it authenticates you with a username and a password or personal access token, sent over an encrypted HTTPS connection.

SSH, as covered above, authenticates you with a key pair instead of a password or token.

Neither is objectively "more secure" in a blanket sense — both are strong when configured correctly. The real difference is convenience and threat model. SSH avoids ever transmitting a reusable secret and skips repeated prompts, which is why most developers set it up once and forget about it. HTTPS is faster to get started with and works everywhere, including networks or environments where SSH's port is blocked.

Could markdown become the next programming language?

KingUSD — Wed, 12 Aug 2026 10:52:12 +0000

Would it be interesting if all code would just be in plain english? Its a wild concept and AI agents like claude code are using structured .md files or "skill.md" to define entire repeatable workflows.

Markdown is not just for formating or writing articles anymore, its becoming a lightwieght way to program and easy to be understood by AI agents

Markdown has a whole ecosystem formed around it, MCP (Model Context Protocol), and AI harnesses that connect agents to real eternal tools. AI harnessing is scaffolding a model and turning it from a chatbot into something that can actually do things.

It has some limitations that doesnt make it a real trade off as per now August 2026, things like token cost, hallucinations and workflow entropy.

so with vast change in technology could markdown become the next programming language?