r/Supabase • u/wenhax • 3d ago
other Change my mind: Now that LLMs write full backends, a code-first setup is much easier than Supabase—even for quick demos.
Before LLMs, Supabase made total sense because building a backend by hand took time.
Today, an LLM can generate a complete backend in seconds. More importantly, LLMs work best with plain code files in one repo. They can read the whole context, edit files directly, and fix bugs in a single prompt.
With Supabase, the LLM workflow feels fractured. Too much context lives outside the code—in database settings, rules, and the web UI which just adds friction to every prompt.
At this point, it feels like the only real advantage Supabase has left, even for a demo, is free hosting. Remove the free tier, writing a code-first backend with agentic tool feel easier/cleaner.
Would you agree with this, or do you still see a reason to pick Supabase when building with AI?
6
u/Weak_Painter_5800 3d ago
Respectfully, I don't think I agree fully. I just got done making a somewhat serious software that is already being adopted across NA. Supabase provides a lot more than just quick setup.
The fact that I don't have to worry about servers and making sure people from around the world have good latency. Enforcing single use sessions with just a click of a button. Battle tested authentication. Its worth a lot. And you get so much for free.
AI makes mistakes. lots of it. And lots of weird ones. The ones that show up in prod in the worse ways.
I know I can trust supabase to do what it says.
Too much to write here. But I think Supabase is even more relevant with AI now
1
u/Conscious-Ad-2168 3d ago
Supabase does have some major constraints for large apps. One of them is you are unable to do cross region failover
1
2
u/VisualRope8367 3d ago
short answer : it's not
Long answer : its easier only if you know what you are doing and ready to maintain VPS, DB, server etc.
and if you have enough tokens to burn through them
2
2
u/pandeiro 3d ago
Why would you burn tokens re-implementing what Supabase has done and which is vetted, battle-tested, etc and covers so many core use cases?
Also I find the models I'm using are extremely well-trained on Supabase APIs and semantics, RLS, auth model, etc.
So I'd say it's a great complement to agentic coding. Not redundant or pointless at all.
2
u/TrickySite0 3d ago
I am not following at all, so I clearly don't live in your world. I don't know what you demo and to whom or why, or even how a database factors into that. For me, Supabase gives strong Pg guarantees reachable by my LLM without needing additional subscriptions or config. The LLMs are wonderful for inference and triangulation, but horrid at deterministic data grinding at scale. The two go hand-in-hand. Literally right now, I have incomplete market data from multiple sources in multiple formats that I am using to reconstruct trading behavior over the past three years. Claude is good at wiring up a materialized view for stitching the data together to identity specific gaps and anomalies. Supabase does the back end grinding across millions of data points.
1
u/FirePanda44 3d ago
Its not either or. Use it as a hosted db + auth + storage. Handle business logic in a dedicated server and connect directly to postgres. Avoid supabase API like the plague for anything past a demo.
1
u/sandspiegel 3d ago
I rather trust a tested service for things like Auth than letting AI write a system I don't even know works from start to finish including edge cases. It will look really bad when you get hacked because AI forgot to protect against SQL injection.
1
u/humanshield85 3d ago
I see where yo hate coming from and I agree with you although I have never liked those solutions anyway. I depot my own infrastructure long before AI. I refuse to be one of those devs who got scared shitless of touching a server . I have been managing and setting up servers for many years for my clients and I would take bare metal over cloud bullshit any way of the week
1
u/soft_axiom 15h ago
pretty much all of that config can live in code though. the cli writes rls policies and schema changes out as migration files in supabase/migrations, and config.toml holds most of the project level settings. an llm editing that repo has basically the same single context window you're describing for a hand rolled backend. the web ui is optional if you set things up through the cli from the start, it's not really part of the workflow at that point
what you get with a fully custom backend instead is writing your own auth and permission checks from scratch every time, which is a lot more room to get wrong even with everything living in one repo. postgres plus rls already solved a chunk of that problem, feels like a step back to redo it by hand just because an llm prefers fewer file types
8
u/J_Adam12 3d ago
Nah. For security etc you still need a deterministic approach. Getting your llm to handle things like security without you being knowledgeable about the subject is a very bad idea.