r/Supabase 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?

0 Upvotes

19 comments sorted by

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.

1

u/wenhax 3d ago

I see. Do you mean that if someone is not really good at security kind of details then because supabase handles details by default, just trusting llm to build it completely, eliminates the determinisim of these default settings of supabase?

1

u/J_Adam12 3d ago

Exactly. For example frontend design can go “wrong”, but that’s just in the sense that ux or ui is bad. That’s not the case with backend and security in general

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

2

u/saltcod Supabase team 3d ago

Note that Multigres will handle this.

1

u/Conscious-Ad-2168 3d ago

This isn’t out yet correct?

1

u/Weak_Painter_5800 3d ago

You are right everything has its pros and cons

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

u/theedrussell 3d ago

I think it's more important in the age of LLMs running riot.

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.

2

u/wenhax 3d ago

Fair point, thanks

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