Your Supabase Is Public If You Turn Off Rls
Key topics
The debate rages on around Supabase's security defaults, with some commenters pointing out that unskilled developers often bypass security controls out of convenience, while others argue that the platform's auth schema is intentionally secured and not exposed to the REST API. The original author concedes that Supabase doesn't create a public users table by default, but wonders why developers feel compelled to create a new users table, sparking a discussion on the need for application-specific user data storage. As the conversation unfolds, parallels are drawn with other platforms, such as Firebase and AWS S3, which have also struggled with users misconfiguring security settings, highlighting a broader issue in the developer community. The thread remains relevant as it shines a light on the delicate balance between security and usability in database management.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
2h
Peak period
34
3-6h
Avg / period
8.3
Based on 66 loaded comments
Key moments
- 01Story posted
Dec 22, 2025 at 11:14 AM EST
14 days ago
Step 01 - 02First comment
Dec 22, 2025 at 1:18 PM EST
2h after posting
Step 02 - 03Peak activity
34 comments in 3-6h
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 24, 2025 at 5:40 AM EST
12 days ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
But what the docs don't cover is the provided Users table. Missing documentation is why I gave up on Supabase; and the Users table was one of the first problems I encountered. Upon creating a new user, values get set in this table for no apparent reason. So if your application depends on knowing the verification status of a new user (for example), good luck... Supabase claimed every user was verified upon creation.
These have gotten much less annoying to use now that it’s controlled through the config.toml.
While in theory your API can be the database it seems like a footgun for the inexperienced and AI.
we have so many data breach because they lack "common basic" security best practices, we aren't talking about state level hacker here
just public bucket storage and so on
eg I was trying to help her set up a webhook listener, and it undid our efforts.
These tools seem incapable of building software in the hands of users who don't understand security already.
These tools are for augmentation of skills, not for wholesale "imma a programmer now", which a lot of people seem to think. And to be honest, lots of companies are selling that "experience" too, even though they know it isn't true, a bit shit.
My colleague now understands why unit tests, after watching subsequent development regularly break previous work. Lovable doesn't support them. And I don't want to touch this codebase because I don't want to own it.
Lovable is not going to tell them to use a proper auth service or fully secure their data. One Lovable project I looked at had generated an entire custom JS Markdown parser instead of using react-markdown, for example.
I had to double take back to the article after reading this - it actually says $330M (raised at $6.6B valuation).
to ask it to use a library,
if that’s what you intend for your codebase?
Assume LLMs and AI products are a rockstar junior dev until proven otherwise. Act accordingly!
It's bad that some folks want to make money on such people doing it anyway, which means they're not very nice and should get help to correct their ways.
I've found doing this, and regularly asking "did you just make my system massively insecure" help keep it on its toes.
That said, I've seen a few "look what I just made.." that caused a double take.
Read this for a high level overview useful for HN: https://community.qbix.com/t/streams-plugin-access-control/2...
You have to explicitly create a read-all policy for anon keys, and with no constraints, for people to get access to it.
The default is secure.
If you turn off RLS, there are warnings everywhere that the table is unsecured.
The author goes on to compare this with PocketBase, which he says you "have to go out of your way" to make insecure. You have to go out of your way with Supabase, as well!
I wonder if the author tested this? I do agree that some third party website builders who use supabase on the back end could have created insecure defaults, but that's not supabase's fault.
The tldr is that Supabase makes this less secure by default because Security is Hard and they don’t want to scare off new users
The fact that it takes a whole thread of conversation to even unwrap whether the default approach they took is good enough is a strong signal to me that it isn’t, because that level of complexity in the implementation often implies a model with a large enough attack surface with weaknesses that can be exploited without too much effort
Submitters: baity and misleading titles are against the site guidelines, so please don't post them here.
https://news.ycombinator.com/newsguidelines.html
This is one reason why Firebase was such a gold-mine for security researchers: everyone just forgot about security when they forgot about their backend.
To me it’s important to make this disambiguation. One take says that auth in db itself is a problem. The other take says “auth in db is a symptom of low code garbage”
I think the feature is there not necessarily because it’s the best technical idea but instead because of its ability to pull in less educated developers. That makes sense financially because there are fewer people out there with a higher degree of expertise. But from my perspective it shows that it’s not meant for me.
https://pierce.dev/notes/go-ahead-self-host-postgres#user-co...
Yugabyte is the best open source postgres for HA.
https://status.yugabyte.cloud/history
You should not run a payment gateway on an inexperienced team. Start with something with lesser risk and then introduce the team to things like load balancers, keepalived, clustering and so on over time.
An hour of downtime is a lot once HA is something to invest in, and the first thing you need to do when there's an incident is to tell your customers what you're doing about it and the second thing they want to know is whether it will happen again. Since I don't know how Yugabyte works I'm not sure about the degree of lock-in, but preferably you should have an incident process where you at minute ten or so of downtime boot load balancing with a customer facing message at another infra provider and update DNS records, then start to rebuild the system there in parallel with the main incident response.
We're constantly striving to improve the user experience and the quality of StackGres. Would you mind sharing some feedback as to what made your experience not good with it?
Did you join the Slack Community (https://slack.stackgres.io/) to ask if you were facing some trouble? It always helps, even if it is just by sharing your troubles.
(If you'd like to share feedback and do so privately, please DM on the Slack Community)
Your feedback will be much appreciated.
That certificate expiry issue was unfortunate, but was resolved (if I'm not mistaken) a couple of years ago.
StackGres is just a control plane, your database is as stable as a standalone one. StackGres itself may fail and it won't affect your database, it's not on the data plane. Indeed, it has a feature to "pause it" if you need to perform some manual operations (otherwise everything is automated).
There are procedures to reconstruct a database from PVC. It's arguably tedious, but should be much simpler than running a Postgres pod without the help of an operator like StackGres.
As for the ratio of issues: most of the issues that we get are feature and/or extensions requests, and certainly we can't tackle them all. Most, if not all, outstanding issues are addressed within a reasonable time frame. Is there any particular issue that would itch you that is open? I'd be happy to personally review it. Yet, there are as of today more than 2K closed issues, I won't call that a small number.
I'd also weight the importance of issues, like the split brain that CNPG suffers [1] and that apparently won't even be solved. StackGres relies instead on the trusted and reputed Patroni, which is known NOT to risk split brains that could lead to severe data loss.
[1]: https://github.com/cloudnative-pg/cloudnative-pg/discussions...
Yep. Probably the most relatable tech friend thing to do. I send my projects to friends and get a list of improvement suggestions, it's always fun!
Only thing it actually makes easier is auth. Other stuff just becomes harder to maintain. A simple springboot Java app, especially with basic boilerplate implemented with llm help, will last a long time, be cheap+simple to host, easily extensible.
https://imgur.com/KBnmRSq
Just FYI, this is what users see when they try to turn off RLS in a public table (it is on by default). We also show security issues in the project homepage and red alerts in the table editor.
I mean, Supabase strongly emphasizes using RLS in every part of the dashboard. They literally advise you everywhere not to expose the database data anywhere client side.
[1] https://www.cs.tau.ac.il/~mad/publications/sigmod2023-rls.pd...
and/or
- Turn off the REST API (if you just use pg connections)
- Disable the JWT/anon token(s)
Yep: https://supabase.com/docs/guides/auth/managing-user-data
> For security, the Auth schema is not exposed in the auto-generated API. If you want to access users data via the API, you can create your own user tables in the public schema.
As one vibe-coding's most fervent critics, I don't blame it at all. Amateur devs have been doing this for a decade and change with Firebase and other hosted datastores.
I got one of my first small jobs as a contractor because of an Android app doing this back in 2012!