Where database blog posts get flame-broiled to perfection
Ah, yes. Another dispatch from the promised land. A world where domain-driven design isn't just a book we all bought and never finished, but a magical incantation that solves the fundamental problem of people writing bad code. The problem, you see, wasn't the lack of constraints; it was that we developers were misunderstood. Our impulsive, schema-breaking commits were just our inner artists trying to align the data model with business logic. My mistake. I’ll be sure to tell that to the on-call engineer at 3 AM next time a null orderId brings down the entire checkout service.
It’s just so empowering to read that my PTSD from the Great users_v2 Migration of 2022 was simply a "misperception." The article claims DBAs are just clinging to their relational safety blankets because they don't trust us. No, no. We trust ourselves. We've seen what we do when left unsupervised. I've seen a user document that started with five fields and, three years later, looked like a Jackson Pollock painting of key-value pairs, half of which were deprecated but nobody was brave enough to delete.
The data model evolves alongside the development process — brainstorming ideas, prototyping, releasing a minimum viable product (MVP) for early feedback and iterating toward a stable, production-ready application.
This is my favorite sentence. It’s so optimistic, so clean. It conveniently omits the part where the "MVP" user.address field (a single string) has to coexist with the "V2" user.addresses (an array of objects), and the "V3_International" user.shipping_info (a nested document with its own sub-fields), all because we can’t afford the downtime to write a migration script. "The data model evolves," they say. Yes, it evolves like a tumor.
And the praise for "schema-flexible"! Oh, that’s a classic. "Schema-flexible, not schema-less." That's what they told us before the last project. It’s a brilliant marketing trick, like saying something is "water-resistant, not waterproof." It means the exact same thing when your phone is at the bottom of a pool, and it means the exact same thing when you're trying to query a collection where the created_at field is variously a Unix timestamp, an ISO 8601 string, and, for three terrifying weeks in 2021, a JavaScript Date object stored as a string. But at least we didn't have to run a DDL statement! Our development velocity was through the roof!
I love the part about how MongoDB maps so "naturally" to UML concepts. Yes, it all looks so neat in a diagram. Composition is just embedded documents. Simple! Until you realize that your order document with its embedded order_lines is now 15 MB and takes half a second to load because one customer ordered every single screw we sell. But don't worry, we'll just refactor that to use references. Which, let's be honest, is just a foreign key that you have to manage yourself, without any of the database-level guarantees. What could possibly go wrong?
This is the best part, though. My absolute favorite bit of corporate hand-waving:
MongoDB can log a warning, alerting the team without disrupting user operations.
Translation: you can now write invalid data to the database and it will fail silently. It’s not a bug, it’s a future PagerDuty ticket! I can see it now. A sea of log warnings that everyone ignores because the system is "still available," right up until the quarterly reporting job falls over because it finally hit one of those documents with a price field that’s a string containing "TBD" and the whole analytics pipeline chokes. No disruption to users, just a minor heart attack for the data science team and an emergency hotfix on a Friday afternoon.
And the final utopian vision: "referential integrity is maintained through business rules." My god. This is like removing all the traffic lights and stop signs and saying, "public safety will be maintained by drivers following the social contract." We all know how that ends. I have lived this nightmare. A developer writes a "simple" cleanup script to delete test users. The script doesn't check for associated orders because that logic is in a different microservice. Congratulations, you now have a few thousand orphaned order documents pointing to user IDs that no longer exist. But don't worry, we can just "run a periodic aggregation pipeline that asynchronously detects anomalies." Finding out your data is corrupt after the fact isn't a feature; it's called a post-mortem. It's a digital Pompeii—we can perfectly preserve the moment of our failure for future generations to study.
So yes, let's all embrace this new paradigm. Let’s move our schema into our application code, where it can be duplicated across twelve different microservices, each with its own slightly different interpretation of what a "product" is. Let's replace database constraints with hopeful comments and JIRA tickets.
It will be great. Everything will be fast and flexible and iterative.
And in 18 months, I'll be here at 3 AM, writing a monstrous script to migrate all this beautifully "flexible" data into a rigid, structured, and blessedly predictable PostgreSQL database. And some VPE will write a blog post about how we’re “rediscovering the value of strong data integrity.”
I can’t wait. I'll start brewing the coffee now.