🔥 The DB Grill 🔥

Heh. Alright, settle down, kids, let The Relic pour himself another cup of lukewarm coffee and read what the geniuses over at "HotStorage'25" have cooked up this time. OrcaCache. Sounds impressive. Probably came up with the name before they wrote a single line of code.

So, let me get this straight. You've "discovered" something you call a disaggregated architecture. You mean... the computer is over here, and the disks are over there? And they're connected by a... wire? Groundbreaking. Back in my day, we called that a "data center." The high-speed network was me, in my corduroy pants, running a reel-to-reel tape from the IBM 3090 in one room to the tape library in the other because the DASD was full. We had "flexible resource scaling" too; it was called "begging the CFO for another block of storage" and the "fault isolation" was the fire door between the server room and the hallway.

And you're telling me—hold on, I need to sit down for this—that sending a request over that wire introduces latency? Shocking. Truly, a revelation for the ages. Someone get this team a Turing Award.

So what's their silver bullet? They're worried about where to put the cache. Should we cache on the client? On the server? Both? You've just re-invented the buffer pool, son. We were tuning those on DB2 with nothing but a green screen terminal and a 300-page printout of hexadecimal memory dumps. You think you have problems with "inefficient eviction policies"? Try explaining to a project manager why his nightly COBOL batch job failed because another job flushed the pool with a poorly written SELECT *.

Their grand design, this OrcaCache, proposes to solve this by... let's see... "shifting the cache index and coordination responsibilities to the client side."

Oh, this is rich. This is beautiful. You're not solving the problem, you're just making it the application programmer's fault. We did that in the 80s! It was a nightmare! Every CICS transaction programmer thought they knew best, leading to deadlocks that could take a mainframe down for hours. Now you're calling it a "feature" and enabling it with RDMA—ooh, fancy—so the clients can scribble all over the server's memory without bothering the CPU. What could possibly go wrong? It’s like giving every driver on the freeway their own steering wheel for the bus.

And the best part? The proof it all works:

A single server single client setup is used in experiments in Figure 1

You tested this revolutionary, multi-client, coordinated framework... with one client talking to one server? Congratulations. You've successfully built the world's most complicated point-to-point connection. I could have done that with a null modem cable and a copy of Procomm Plus.

Their solution for multiple clients is even better: a "separate namespace for each client." So, if ten clients all need the same piece of data, the server just... caches it ten times? You've invented a way to waste memory faster. This isn't innovation, it's a memory leak with a marketing budget. And they have the gall to mention fairness issues and then propose a solution that is, by its very nature, the opposite of fair or collaborative.

Of course, they sprinkle in the magic pixie dust: "AI/ML workloads." You know, the two acronyms you have to put in every paper to get funding, even though you didn't actually test any. I bet this thing would keel over trying to process a log file from a single weekend.

But here's the kicker, the line that made me spit out my coffee. The author of this review says the paper's main contribution is...

reopening a line of thought from 1990s cooperative caching and global memory management research

You think? We were trying to make IMS databases "cooperate" before the people who wrote this paper were born. We had global memory, alright. It was called the mainframe's main memory, and we fought over every last kilobyte of it with JCL and prayers. This isn't "reopening a line of thought," it's finding an old, dusty playbook, slapping a whale on the cover, and calling it a revolution. And apparently, despite the title, there wasn't much "Tango" in the paper. Shocker. All cache, no dance.

I'll tell you what's going to happen. They'll get their funding. They'll spend two years trying to solve the locking and consistency problems they've so cleverly ignored. Then they'll write another paper about a "revolutionary" new system called "DolphinLock" that centralizes coordination back on the server to ensure data integrity.

Now if you'll excuse me, I think I still have a deck of punch cards for a payroll system that worked more reliably than this thing ever will. I need to go put them in the correct order. Again.