🔥 The DB Grill 🔥

Alright, settle down, kids. Let me put down my coffee—the kind that's brewed strong enough to dissolve a floppy disk—and read this... this press release.

Oh, wonderful. "Neki." Sounds like something my granddaughter names her virtual pets. So, you've taken the shiniest new database, Postgres, and you're going to teach it the one trick that every database has had to learn since the dawn of time: how to split a file in two. Groundbreaking. Truly, my heart flutters with the thrill of innovation. You've made "explicit sharding accessible." You know what we called "explicit sharding" back in my day? We called it DATABASE_A and DATABASE_B, and we used a COBOL program with a simple IF-THEN-ELSE statement to decide where the data went. The whole thing ran in a CICS region and was managed with a three-inch binder full of printed-out JCL. Accessible.

They say it's not a fork of Vitess, their other miracle cure for MySQL. No, this time they're architecting from first principles.

To achieve Vitess’ power for Postgres we are architecting from first principles...

First principles? You mean like, Edgar F. Codd's relational model from 1970? Or are you going even further back? Are you rediscovering how to magnetize rust on a plastic tape? Because we solved this problem on System/370 mainframes before most of your developers were even a twinkle in the milkman's eye. We called it data partitioning. We had partitioned table spaces in DB2 back in the mid-80s. You'd define your key ranges on the CREATE TABLESPACE statement, submit the batch job, and go home. The next morning, it was done. No "design partners," no waitlist, no slick website with a one-word name ending in .dev.

And the hubris... "running at extreme scale." Let me tell you about extreme scale, sonny. Extreme scale is watching the tape library robot, a machine the size of a small car, frantically swapping cartridges for a 28-hour end-of-year batch reconciliation. It's realizing the backup job from Friday night failed but you only find out Monday morning when someone tries to run a report and the whole system grinds to a halt. It's physically carrying a box of punch cards up three flights of stairs because the elevator is out, and praying you don't trip. That's extreme. Your "extreme scale" is just a bigger number in a billing dashboard from a cloud provider that's just renting you time on... you guessed it... someone else's mainframe.

They're "building alongside design partners at scale." I love that. We had a term for that, too: "unpaid beta testers." We'd give a new version of the payroll system to the accounting department and let them find all the bugs. The only difference is they didn't get a featured blog post out of it; they got a memo and a stern look from their department head.

So let me predict the future for young "Neki":

• You'll spend two years reinventing distributed transactions, and then you'll write a long, self-congratulatory blog post about how you've created a "novel two-phase commit protocol." We had that in the 80s. It was slow and unreliable then, too.
• Someone will discover that a network partition causes silent data corruption, a problem we solved with checksums on 9-track tapes forty years ago.
• The "first principles" architecture will eventually just look like a Rube Goldberg machine of microservices trying desperately to emulate the stability of a single, boring old monolith.

And in five years, when this whole sharded mess becomes an unmanageable nightmare of distributed state and cross-shard join-latency, PlanetScale will announce its next revolutionary product: a tool that seamlessly "un-shards" your data back into a single, robust Postgres instance. They’ll call it "cohesion" or "unity" or some other nonsense, and a whole new generation of developers will call it revolutionary.

Now if you'll excuse me, I've got a cryptic error code from an IMS database to look up on a microfiche. Some of us still have real work to do.