A year ago I worked on a web service that had Postgres and Elasticsearch as backends. Postgres was doing most of the work and was the primary source of truth about all data, but some documents were replicated in Elasticsearch for querying. Elasticsearch was easy to get started with, but had an ongoing maintenance cost: it was one more moving part to break down, it occasionally went out of sync with the main database, it was another thing for new developers to install, and it added complexity to the deployment, as well as the integration tests. But most of the features of Elasticsearch weren’t needed because the documents were semi-structured, and the search queries were heavily keyword-based. Dropping Elasticsearch and just using Postgres turned out to work okay. No, I’m not talking about brute-force string matching using LIKE expressions (as implemented in certain popular CMSs); I’m talking about using the featureful text search indexes in good modern databases. Text search with Postgres took more work to implement, and couldn’t do all the things Elasticsearch could, but it was easier to deploy, and since then it’s been zero maintenance. Overall, it’s considered a net win (I talked to some of the developers again just recently).

I gave a talk last month at the Sydney Python user group called Relational Databases Considered Incredibly Useful. I presented a lot of examples of ways relational databases can be used (and, some would say, abused). The point wasn’t that relational databases are a great tool for all those jobs, but that relational databases are often “good enough”, and can save complexity budget for where it’s needed. Building real-world applications requires solving a lot of subproblems, and most of those subproblems don’t need big solutions like the ones you seen in blog posts from big tech companies. Even the big tech companies are solving most of their problems in mundane ways; they just don’t normally publish papers or highly upvoted blog posts about it. Stack Overflow runs on four Microsoft SQL Server instances (and most of their servers are for redundancy and geographic distribution, not capacity).

Relational databases have survived nearly half a century of being killed by new hotness (most of which is now forgotten). In the 90s, relational databases were going to be obsoleted by object databases. Then, at the turn of the century, XML was going to change everything about how we handle data. After that, in the late 00s, webscalability demanded ditching the relational model for NoSQL. But relational databases are still popular today, even in greenfield projects. That doesn’t mean relational databases will stay forever, but it proves that they’re pretty damn useful, and whatever replaces them will have to be pretty damn good.