I need you to understand something about my relationship with SQL Server on Azure. It’s like dating someone who insists on ordering the lobster thermidor at every restaurant, then looks you dead in the eye and says we’re splitting this, right?
Meanwhile, Postgres is sitting at the next table over, quietly enjoying a perfectly good meal that costs about as much as your appetizer, wondering why you keep doing this to yourself.
Let me paint you a picture.
The Invoice That Launched a Thousand Spreadsheets
Last quarter, our finance team sent me an email with the subject line “URGENT: Database Costs.” The urgency was real. Our SQL Server on Azure spend had grown so aggressively that Janet from accounting thought we’d been hacked. We hadn’t been hacked. We’d just provisioned a few extra vCores because Brad in engineering said he might need them for a project that never materialized.
Brad’s ghost project cost us $847 per month. For computing power that sat there like an expensive treadmill in someone’s basemen that never got used.
I ran the numbers. Our three-node SQL Server setup with high availability (because heaven forbid we experience thirty seconds of downtime for our internal dashboard that exactly four people check on Wednesdays) was running us roughly $4,200 monthly. That’s $50,400 a year. For a database supporting an application with the traffic profile of a small-town library on a Tuesday afternoon.
For context, I could fly first-class to an actual database conference in Stockholm, take a week-long vacation, buy everyone at the conference a drink, and still have enough left over to subscribe to seventeen different project management SaaS tools we’d never use.
The Postgres Revelation
Then someone mentioned Postgres.
Actually, that’s not quite accurate. Someone didn’t mention Postgres. Our new CTO, bless her practical heart, looked at our Azure bill during her first week and said, verbatim, Why are we cosplaying as Goldman Sachs when we’re basically a mid-sized vendor with delusions of grandeur?
She wasn’t wrong.
We spun up a comparable Postgres instance on Azure (yes, Azure has Postgres, shocking revelation for those of us who thought Microsoft only acknowledged the existence of Microsoft products). The cost? About $380 per month for similar performance characteristics1. That’s roughly nine percent of what we were paying for SQL Server.
Nine. Percent.
I had to check my spreadsheet three times because I thought I’d accidentally divided by the wrong column. I hadn’t. SQL Server was just that expensive, sitting there in our Azure subscription like a luxury car parked in a garage we rarely opened.
But What About Enterprise Features?
This is where the SQL Server defenders emerge from the woodwork, clutching their Windows Server licenses and talking about enterprise-grade reliability like it’s a religious doctrine.
What about Always On Availability Groups? they ask, as if our employee directory application requires the same uptime guarantees as a cardiac monitoring system.
What about SQL Server Integration Services? they demand, conveniently forgetting that we use it for exactly one ETL job that could be replaced by a Python script and a cron job.
What about the tight integration with the Microsoft ecosystem? they plead, as if our seven-year-old .NET application couldn’t talk to Postgres with a simple connection string change and maybe an afternoon of minor refactoring.
Here’s the thing about enterprise features: they’re lovely when you need them. They’re financial masochism when you don’t. One giant bucket of opportunity cost.
We didn’t need them. We were paying for Always On availability for systems that could survive a twenty-minute outage without anyone noticing. We were paying for SQL Server’s comprehensive tooling to run queries we could write in any standard SQL dialect. We were paying for integration services we’d basically abandoned in favor of doing the same work in Airflow (another subscription, naturally, because why solve problems when you can layer tools on top of them like sedimentary rock).
The Hidden Costs They Don’t Put in the Pricing Calculator
But wait, there’s more. (I’ve always wanted to say that in a professional context, and database cost analysis is apparently that context.)
SQL Server on Azure doesn’t just charge you for compute and storage. Oh no. That would be too straightforward, too honest, too much like a transaction between consenting adults who respect each other’s time.
You’re also paying for:
Backup storage. Because your backups need their own line item, separate from your actual storage, like some kind of meta-database watching over your database.
Data egress. Want to download your own data? That’ll be extra, thank you very much. It’s like paying rent, and then paying again every time you want to retrieve something from your apartment.
High availability compute. You’re not just paying for your primary database instance. You’re paying for the ghost instance sitting in another availability zone, doing nothing except existing in case the first one has a bad day. Which is fine! Redundancy is good! But Postgres offers the same capability at a fraction of the cost.
Licensing. Even on Azure, even in the cloud, SQL Server carries the specter of its licensing heritage. You’re paying Microsoft for the privilege of using their database, then paying Azure for the privilege of running it on their infrastructure. It’s licensing inception.
The Migration That Wasn’t
I should mention that we haven’t actually migrated yet. This is the part of the story where I’m supposed to tell you about our triumphant database transformation, how we saved the company fifty grand annually, and how I got promoted to Senior Director of Cost Optimization and Common Sense.
Instead, we’re still running SQL Server.
Why? Because migrations are scary. Because our application has some stored procedures that someone wrote in 2016 and nobody fully understands. Because Brad—yes, the same Brad from the ghost project, said switching databases sounded risky during a stand-up, and now everyone thinks we’re one connection string away from catastrophic data loss.
Also, our SQL Server instance is now technically legacy infrastructure, which means it has achieved a kind of untouchable status. Like a historic building we can’t demolish even though it’s costing us a fortune and nobody really likes looking at it.
So we keep paying. Month after month. $4,200 disappearing into Azure’s billing event horizon, while our Postgres proof-of-concept sits in a separate resource group, quietly demonstrating that we could save $46,000 annually if we simply had the collective courage to change a configuration file.
The Moral of This Financially Painful Story
Look, SQL Server is fine. Great, even, if you’re running mission-critical systems at massive scale with complex integration requirements and compliance needs that would make a lawyer weep with joy.
But most of us aren’t. Most of us are running departmental applications, internal tools, and systems that would survive just fine on Postgres while leaving enough budget left over to actually hire another engineer instead of spending that salary on database licensing.
The real cost isn’t just the money. It’s the opportunity cost of what we could build, who we could hire, or what tools we could properly utilize if we weren’t hemorrhaging cash on database infrastructure that’s wildly over-specified for our actual needs.
Our Postgres instance is still there, waiting patiently in its resource group. A monument to fiscal responsibility and practical decision-making. A reminder that sometimes the right answer is the boring one that costs ninety-one percent less.
We’ll migrate eventually. Probably. After we finish our current roadmap. And the Q3 planning. And after Brad finishes his new project, which will definitely happen this time.
Until then, I’ll keep explaining to Janet why our database costs more per month than her car payment. She’s stopped asking questions. I think she’s just accepted that this is how we do things now.
At least we have high availability.
Be Seeing You,
Kyle
This is key as there are some places such as perhaps simultaneous connections where SQL Server out performs Postgres. Horses for courses.
A great read and a good chuckle while sipping my morning cuppa on a lazy Sunday morning posing as a Microsoft SQL guru :) Thanks Kyle. Miss your sense of humor every day.