Where database blog posts get flame-broiled to perfection
Oh, this is just a fantastic read. Thank you so much for sharing. I’ll be sure to pass this along to our new junior dev; he’s still got that glimmer of hope in his eyes, and I think this will help manage his expectations.
I particularly love the enthusiastic embrace of flexibility. The idea that a field can be a scalar in one document and an array in another is a true masterstroke of engineering. It brings back such fond memories of my pager screaming at me because a critical service was getting a TypeError trying to iterate over the integer 42. Who could have possibly predicted that? It's this kind of spicy, unpredictable schema that keeps the job interesting.
And the core thesis here is just… chef’s kiss. The revelation that sorting and comparison for arrays follow completely different logic is a feature, not a bug.
⚠️ Ascending and descending sorts of arrays differ beyond direction. One isn't the reverse of the other.
This is my favorite part. It’s a beautiful, elegant landmine, just waiting for an unsuspecting engineer to build a feature around it. I can already picture the emergency Slack channel. “But the query works perfectly for sort: -1! Why is sort: 1 showing me documents from last year?!” It’s the kind of subtle “gotcha” that doesn’t show up in unit tests but brings the entire payment processing system to its knees during Black Friday. Game-changing.
The proposed solution is also wonderfully pragmatic. When the default behavior of your database is counter-intuitive, what’s the fix? Just whip up a quick, totally readable $addFields with a $reduce and $concat inside an aggregation pipeline. It’s so simple! Why would anyone want ORDER BY to just… work? This is so much more engaging. It’s like buying a car and discovering the brake pedal only works if you first solve a Rubik's Cube. Thrilling.
Honestly, the deep dive into explain("executionStats") gave me a little jolt of PTSD. Staring at totalKeysExamined: 93 and dupsDropped: 77 felt a little too familiar. It reminds me of a few of my past battle companions:
userId, user_ID, and my personal favorite, uid, which was sometimes an int and sometimes a UUID string.Seeing the elaborate PostgreSQL query to replicate Mongo’s “index-friendly” behavior was truly illuminating. It really highlights how much tedious, explicit work Postgres makes you do to achieve the same level of beautiful, implicit confusion that Mongo offers right out of the box. You have to tell Postgres you want to sort by the minimum or maximum element in an array. What a hassle.
Thank you again for this thoughtful exploration. You’ve really clarified why this new system will just create a fresh, exciting new vintage of production fires for us to put out. It’s comforting to know that while the problems change, the 3 AM debugging sessions are eternal.
Truly, a fantastic article. I’ve saved it, printed it out, and will be using it as a coaster for my fifth coffee of the day. I promise to never read your blog again.