Where database blog posts get flame-broiled to perfection
Alright, settle down, kids. Grandpa Rick's just finished his coffee and read this... press release. Took me longer to get through the buzzwords than it used to take to re-spool a 9-track tape. You've got a database, inside a database, that talks to another database in the "cloud." Groundbreaking. I haven't seen a architecture this convoluted since someone tried to explain microservices to me.
Let's unpack this marvel of modern engineering, shall we?
So you want to "seamlessly combine OLTP and OLAP queries." I've got a filing cabinet full of project proposals from 1988 that promised the exact same thing. We called it "a really bad idea" back then, too. You know what happens when you run a massive analytical query on the same box that's processing live transactions? The whole thing grinds to a halt. It's like trying to land a 747 on a carrier deck while the crew is having lunch. But wait! The very next section says you should separate them with MotherDuck! So which is it, geniuses? Are we combining or separating? It feels like you're selling me a car with two engines, but telling me to only use one at a time.
An "extension that integrates DuckDB's column-store analytics engine right inside of Postgres." Wonderful. Just bolt another engine onto the side. What could possibly go wrong? Back in my day, our databases were monolithic, predictable, and about as exciting as watching paint dry—which is exactly what you want from a database. This is a turducken of technical debt. You've got a row-store engine and a column-store engine living in the same memory space, probably fighting over resources like two toddlers over a single juice box. I can already hear the support calls. "I ran a VACUUM and my duck flew away!"
Then there's the grand journey of a query. Let me see if I have this straight. A query starts in your PlanetScale Postgres database, gets handed off to the pg_duckdb extension, which then makes a network call with a secret token to MotherDuck in the cloud. MotherDuck runs the query on its own compute against its own data, and then sends the results all the way back to Postgres. We used to have a name for this: an ETL job. We ran it overnight, it was written in JCL that a man could understand, and it didn't require three different mascots to explain.
You're celebrating that this "unifies the experience." Unifies what, exactly? My anxiety? You've unified a stable OLTP database with an in-process analytical engine that you're encouraging me not to use in favor of a third-party cloud service. This isn't unified, it's just tangled. We achieved a "unified experience" with COBOL and DB2. The experience was that it worked. Every. Single. Time. Your "experience" looks like a dependency graph that would make a mainframe scream.
You haven't invented a new paradigm. You've just found a way to glue three different things together and call it innovation.
Now if you'll excuse me, I've got a REORG to schedule. At least when I do that, I know which machine is actually doing the work.