Title partially stolen from Renegade Otter’s brilliant critique YOUR DATABASE SKILLS ARE NOT ‘GOOD TO HAVE’
In the past few years I have been noticing an unsettling trend – software engineers are eager to use exotic “planet-scale” databases for pretty rudimentary problems, while at the same time not having a good grasp of the very powerful relational database engine they are likely already using, let alone understanding the technology’s more advanced and useful capabilities. The SQL layer is buried so deep beneath libraries and too clever by a half ORMs that it all just becomes high-level code.
Andrei Taranchenko
SQL has been around long enough to get its AARP card. Is it ready for retirement? Not by a long shot. Andrei explains:
Serious, mission-critical systems have been running on classic and boring relational databases for decades, serving thousands of requests per second. These systems have become more advanced, more capable, and more relevant….it wasn’t that uncommon in the past to convert certain functions to assembly code in order to squeeze every bit of performance out of the processor. Now compute and storage is cheaper – it’s true – but abusing this abundance has trained us laziness and complacency. Suddenly, that Cloud bill is a wee too high, and heavens knows how much energy the world is burning by just running billions of auto-generated “Squeel” queries every second against mammoth database instances.
Just skimming through the table of contents of your database of choice…you will find an absolute treasure trove of features fit to handle everything but the most gruesome planet-scale computer science problems. Petabyte-sized Postgres boxes, replicated, are effortlessly running now as you are reading this.
The trick is to not expect your database or your ORM to read your mind…and ORMs will happily do the worst possible thing for you in terms of performance…The “just add more CPU and RAM if it’s slow” approach may have worked for a while, but many are finding out the hard way that this kind of laziness is not sustainable in a frugal business environment where costs matter.
It is fairly easy to make a beefy Postgres or a MySQL database grind to a halt if you expect it to do magic without any extra work. “It’s not web-scale, boss. Our 2 million records seem to be too much of a lift. We need DynamoDB, Kafka, and event sourcing!”
A relational database is not some antiquated technology that only us tech fossils choose to be experts in, a thing that can be waved off like an annoying insect...In legal speak, a modern RDBMS is innocent until proven guilty, and the burden of proof should be extremely high – and almost entirely on you.
AMEN. I can’t add much to this, except to offer a theory on why ORMs can get otherwise competent developers into trouble so easily. ORMs abstract away database operations and present them as modular and object-oriented. In reality, they are anything but. Once again, legacy == proven, and you’re always better off making sure you’re getting the most out of your current technology before you add something new and trendy (read: risky) to your application.
The Lair of Leaky Abstractions 
You must be logged in to post a comment.