Since the late 1990s, I worked with Microsoft SQL Server. My employers over the years had standardized on MSSQL for a variety of reasons:

• It was well-integrated with Microsoft Visual Studio and the languages that our developers used to build apps, making it easier to get examples and support
• We used a lot of third party apps (accounting software, payroll, help desk, etc) that were built atop it, so we had to host MSSQL in-house regardless for their apps
• All the way back to the 1990s, it already had a lot of enterprise-y features in the box like Active Directory authentication, high availability, disaster recovery, auditing, etc. (although those features certainly changed over the years)

Microsoft SQL Server always had a reputation for being pricey relative to open source databases like MySQL and PostgreSQL, but I didn’t really care because it wasn’t like I was personally paying out of pocket for it anyway. The database platform was a corporate decision, not my own.

When I started a company, licensing became my problem.

In 2017, when I wanted to build a software-as-a-service database performance monitoring platform, I had to decide where to store the data, and I chose Postgres. Obviously, open source databases have to be cheaper than commercial databases that are licensed per CPU core, right?

The answer isn’t quite as clear-cut as it seems.

For price comparisons, I love instances.vantage.sh, a web front end that’s basically an Excel spreadsheet of various instance sizes and costs. There’s an RDS tab for AWS Relational Database Services, and we’ll pick an 8-core, 64GB RAM VM type:

You can click that image to zoom in, but the short story is that for a db.r5.2xlarge:

• PostgreSQL is about $5,000 USD per year
• SQL Server Standard Edition is about $25,000 per year, or 5x higher

The other way to look at that is for the same price, you can get 2x-4x more hardware with Postgres.

At first glance – especially for small startups – that decision is a no-brainer. Saving $20,000 per year is a genuinely big deal when you’re bootstrapping a company. (Of course, small companies can get by with smaller instance sizes initially, but I’m just using this to illustrate a particular size – you can pick other sizes for comparison if you like.) Our initial projections guessed that we were going to ingest 1TB or more of monitoring data each month, and I didn’t want to spend too much time on performance tuning as opposed to building features.

$20K/year Isn’t Really expensive.

In a vacuum, sure, it’s expensive. If you’re not comparing it to anything else, I’d rather have $20K in my pocket than not.

But… for existing companies…

The equation changes. Existing companies with apps already built on SQL Server already have:

• Staff with proven database development skills
• A lot of management reports (and maybe even data warehouses) built atop it
• Sysadmins and engineers with a track record of caring and feeding it

So if they want to retool the underlying database, it gets really expensive to re-train the existing staff and rewrite your reports. Changing databases underneath a working application is way harder than people expect, and once you start calculating the cost of projects like that, it starts to sound a lot better to just pay an extra $20K/year per server, and kick the financial can down the road a little bit further.

If you’re a SQL Server, Oracle, or DB2 administrator, you might be watching this decision process go down at your own company, and you might be getting smug, thinking, “Management at my company is sticking with my database. My career is fine.” And as long as you stay at that same job, that’s true.

But new apps and new companies are different.

However, for any new app you build, that’s where the decision starts to change:

• You might be hiring new developers to do it (or outside contractors)
• You won’t have any management reports built atop the data yet
• You might not need sysadmins and engineers to care and feed it – if you choose a hosted, managed database like AWS RDS Postgres, Aurora, Azure Database for PostgreSQL, or any one of the other cloud Postgres options

Even at big established companies, over the last several years, I’ve kept hearing the same thing: management is insisting that new app builds revisit the database choice – just as I did back in 2017. They’re not necessarily mandating that all new apps abandon commercial databases, but they’re just requiring architects to open the playing field and explain why the architect isn’t picking an open source database for their foundation.

If you work with a commercial database – like I did – you owe it to yourself to be able to answer management’s questions. You need to be able to say, “Yes, I’m ready to manage and tune open source databases should we choose to implement ’em,” because it keeps you valuable as a data professional. Your job won’t be in jeopardy to a stranger who already knows this stuff – especially a cheaper stranger in a cheaper cost-of-living area.

Because price isn’t just about the cost of the database.

Companies are looking at all prices these days, and you’d better be able to justify your own price too. Learn Postgres now to protect yourself.