A List of Things for You to Ignore

There is a thread somewhere, right now, where two engineers are fighting about databases. One will not budge on Postgres. The other keeps saying MySQL was fine for fifteen years and will be fine for fifteen more. They are both articulate. They are both a little too invested. Stop the argument and ask each of them, quietly, to name the last Postgres feature they reached for on purpose, or the last MySQL behavior they tuned by hand. What do you think you would hear?

A pause. Then a change of subject.

I have spent years watching people defend databases they never chose. Not once did the intensity of the defense have anything to do with the depth of the use. Why would that be?

How did it get there in the first place?

Ask an engineer why the app runs on the database it runs on, and listen for the shape of the answer.

One team I worked with ran on Postgres. Solid choice, everyone agreed. Why Postgres? Because the app was Django, and everyone knows that with Django you use Postgres. Fine. So what did they use of Postgres? Which of the things that make Postgres worth the argument were actually in the schema? Range types? Partial indexes? A single materialized view? JSONB doing something a plain column could not? Nothing. A set of tables with primary keys and a couple of foreign keys, sitting inside one of the most capable open-source databases ever written, using roughly the same five percent of it that any database hands you for free.

Another shop ran on SQL Server. Why? Because the company was a Windows company, and SQL Server is what Windows companies run. At one point someone even tried to build a MySQL-compatible version of the product, then quietly let it rot because no one would maintain two backends. So they stayed. And what did they use of SQL Server, the thing they were now locked to, licensed for, organized around? Which feature justified the bill? Columnstore indexes? In-memory OLTP? Anything you would put on a slide and say this is why we’re here? Nothing. Tables. Primary keys. A stored procedure or two that could have lived anywhere.

Different companies. Different logos on the login screen. The same shape underneath: nobody chose the database. It arrived attached to something else, a framework, an operating system, a hire, and everyone agreed to call the arrival a decision. So when did the arrival become the decision? Can you point to the moment anyone actually chose?

What do you actually use it for?

Here is a strange exercise. Take your production database, the one you would defend in the thread, and list every feature you use that you could not get from literally any other database.

Not the tables. Every database has tables. Not the primary keys, the foreign keys, the WHERE clauses, the transactions you never think about. Those are the intersection of all databases, the common floor. And if your whole application sits on that floor, then what are you actually running? Not Postgres, or MySQL, or SQL Server. The generic relational database that all of them contain, wearing the costume of the specific one you picked.

I watched a social platform run its store on MySQL and its social graph on MongoDB. The Mongo side had no indexes worth the name, no aggregation pipeline, none of the document-model reasoning that is the entire reason you reach for Mongo instead of a table. It was a pile of JSON that the application filtered in memory, because the database was never asked to. The authentication even leaned on Mongo through a library whose access-control layer had a bug, a library that had gone unmaintained for years, so at some point the team forked it just to keep the doors locked. Two databases. Neither used for the thing it was good at. Both defended, when it came up, as our stack.

So the question was never which database is best. If you use only the floor that every database shares, on what grounds did you ever need this one?

Then why would you fight for it?

This is the uncomfortable part, so sit with it for a second before you decide it is about someone else.

The engineer who will fight hardest for Postgres in a thread is very often the one who has never opened EXPLAIN ANALYZE on a slow query. The one who swears by their database is frequently the one who has never watched it think. The loyalty is real. The knowledge is absent. And it is tempting to call that a contradiction, a person who should know more defending something they understand too little.

But what if it is not a contradiction at all? What if the loyalty and the ignorance are the same fact, wearing two faces?

You can give reasons for a choice. We picked this because of that, and here is the tradeoff we accepted. A choice invites you to defend it with arguments, which means it also invites you to be wrong. But a thing you never chose, a thing that simply arrived and became ours, what can you defend it with, if not loyalty? There were no reasons to reach for. So could it be that the less you actually decided, the louder you have to be? Does that describe anyone you have argued with? Does it describe you, the last time you were the loud one?

Who sweeps the floor while you sleep?

Go one level down, past the choice, into the thing itself.

Every serious database is a small operating system with opinions. It decides whether to hand out threads or processes for each connection. It decides how many versions of a row to keep alive at once so that readers and writers do not block each other. It decides when to walk through its own tables and throw out the dead rows that concurrent writes leave behind, the corpses of every UPDATE and DELETE, because in a system built for concurrency an update does not overwrite. It leaves the old version behind and moves on. Someone has to come clean that up. In Postgres that someone has a name. It is called autovacuum, it runs by default, and it is the reason your database does not slowly bloat into a swamp.

When did you last look at autovacuum_vacuum_scale_factor? When did you last notice a table so bloated with dead tuples that every query read ten times the rows it returned? Or has it simply run, and been fine, and never once asked you to look? The floor sweeps itself. Until the day it cannot keep up, the swamp arrives, and someone very expensive is paged in to explain a thing that was in the manual all along.

The database has been doing enormous, invisible work on your behalf this entire time. Concurrency, durability, isolation, the sweeping-up. How much of it could you explain, if the person paying you asked?

But it worked, didn’t it?

And here is where you get to escape, so let me hand you the exit before you take it.

Every one of those shops shipped. The Postgres team that used no Postgres. The Windows shop that used no SQL Server. The social platform with the unindexed Mongo and the forked auth library. They served real users. They made real money. Nobody was fired for the empty choice. That pile of mixed databases ran in production for years and paid salaries, maybe yours.

So on what grounds, exactly, do you call it wrong?

What did the bill actually say?

If none of it mattered, if you can bolt together tools you do not understand, use five percent of each, and still build a business, then maybe understanding your database is a craftsman’s vanity, a thing engineers tell each other to feel serious. Maybe the changelog was always a waste of your afternoon.

Or it mattered enormously, and you simply never got the invoice in a form you could read. Maybe the bill came as the outage that took a day instead of an hour. As the feature that shipped a quarter late because the query could not be made fast. As the migration nobody dared attempt because no one alive understood what the schema was doing. It came, it just never had understand your database printed on the line item.

Which world are you in? Both look identical from the inside, right up until they don’t. Can you actually tell which one you are standing in?

When did you last read the changelog?

So here is the smallest possible version of the question, the one you can check tonight.

A new version of your database shipped recently. It always does. Somewhere in its release notes is a list of features its authors spent a year of their lives building, for problems they were certain you had. When did you last read that list? Not skim the headline. Read it, the way you would read a message written to you.

Because that database has been quietly offering you more of itself, version after version, a year of someone’s work each time, addressed to you. And all the while you have been taking the same table and the same primary key you took on the very first day.

So when, exactly, did you choose it? On the day it arrived attached to a framework, an operating system, a hire? Or every year since, in the small silent act of leaving the letter unopened?

And if you cannot point to the day you chose… whose choice have you been defending all this time?