🔥 The DB Grill 🔥

Where database blog posts get flame-broiled to perfection

Supabase Auth: Build vs. Buy
Originally from supabase.com
August 12, 2025 • Roasted by Rick "The Relic" Thompson Read Original Article

Alright, settle down, kids. Let me put on my bifocals and squint at what the internet coughed up today. "The reasons why (and why not) to use Supabase Auth instead of building your own." Oh, this is a classic. It’s got that shiny, new-car smell of a solution looking for a problem it can pretend to solve uniquely.

Back in my day, "building your own" wasn't a choice, it was the job. You were handed a stack of green-bar paper, a COBOL manual thick enough to stop a bullet, and told to have the user authentication module done by the end of the fiscal year. You didn't whine about "developer experience"; you were just happy if your punch cards didn't get jammed in the reader.

So, this "Supabase" thing... it's built on Postgres, you say? Bless your hearts. You've finally come full circle and rediscovered the relational database. We had that sorted out with DB2 on the System/370 while you lot were still figuring out how to make a computer that didn't fill an entire room. But you slapped a fancy name on it and act like you've invented fire.

Let's see what "magic" they're selling.

They're probably very proud of their "Row Level Security." Oh, you mean... permissions? Granting a user access to a specific row of data? Groundbreaking. We called that "access control" and implemented it with JCL and RACF profiles in 1988. It was ugly, it was convoluted, and it ran overnight in a batch job, but it worked. You've just put a friendly JavaScript wrapper on it and called it a revolution.

You get the power of Postgres's Row Level Security, a feature not commonly found in other backend-as-a-service providers.

Not commonly found? It’s a core feature of any database that takes itself seriously! That’s like a car salesman bragging that his new model "comes with wheels," a feature not commonly found on a canoe.

And I'm sure they're peddling JWTs like they're some kind of mystical artifact. A "JSON Web Token." It’s a glorified, bloated text file with a signature. We had security tokens, too. They were called "keys to the server room" and if you lost them, a very large man named Stan would have a word with you. You're telling me you're passing your credentials around in a format that looks like someone fell asleep on their keyboard? Seems secure.

I bet they talk a big game about "Social Logins" and "Magic Links." It's all about reducing friction, right? You're not reducing friction; you're outsourcing your front door to the lowest bidder. You want to let Google, a company that makes its money selling your data, handle your user authentication? Be my guest. We had a federated system, too. It was called a three-ring binder with every employee's password written in it. Okay, maybe that wasn't better, but at least we knew who to blame when it went missing.

This all comes down to the same old story: convenience over control. You're renting. You're a tenant in someone else's data center, praying they pay their power bill. I remember when we had a critical tape backup fail for the quarterly financials. The whole department spent 72 hours straight in the data center, smelling of ozone and stale coffee, manually restoring data from secondary and tertiary reels. You learn something from that kind of failure. You learn about responsibility.

What happens when your entire user base can't log in because Supabase pushed a bad update at 3 AM on a Tuesday?

They'll show you fancy graphs with 99.999% uptime and brag about their developer velocity. Those metrics are illusions. They last right up until the moment your startup's V.C. funding runs dry, and "Supabase" gets "acqui-hired" by some faceless megacorp. Their revolutionary auth service will be "sunsetted" in favor of some new strategic synergy, and you'll be left with a migration plan that makes swapping out a mainframe look like a picnic.

So go on, build your next "disruptive" app on this house of cards. It'll be fast. It'll be easy. And in eighteen months, when the whole thing comes crashing down in the Great Unplugging of 2026, you'll find me right here, sipping my Sanka, maintaining a COBOL program that's been running reliably since before you were born.

Now if you'll excuse me, my batch job for de-duplicating the company phone list is about to run. Don't touch anything.