SQL Is Easy… And That’s The Problem

🗄️ Almost every software project needs a database to store information, which is why most developers start with SQL or object-based databases. These tools are familiar, flexible, and easy to use out of the box.

But that flexibility comes at a hidden cost.

SQL and object databases allow developers to store data in virtually any structure — even poorly designed ones. Without enforced planning or schema constraints, it’s tempting to skip modeling relationships or typing queries properly. This often leads to messy, unscalable data layers that later cause serious issues: slow queries, painful sharding and replication, unclear data ownership, and access control chaos.

I love PostgreSQL as much as anyone, but in my 25+ years of engineering, I’ve rarely seen teams treat data modeling with the care it deserves. In most cases, schema design happens reactively, not proactively.

That’s why in many of my recent projects, I’ve leaned toward less traditional databases — like Cassandra or AWS DynamoDB. These systems force you to think ahead. You can’t skip modeling. You must define access patterns and data structures upfront. Otherwise, the system simply won’t work.

And that’s a good thing.

Great systems aren’t about enforcing rules manually — they’re about creating environments where the right architecture becomes the path of least resistance.

Watch full video: https://youtu.be/kORcLmvS5OE