https://docs.postgrest.org/en/latest/references/errors.html

For example, if you try to access a table named "secret" that doesn’t exist, Supabase might return a hint saying, "Perhaps you meant the table 'public.super_secret'."

Thanks for volunteering that information, I guess.

Note that the hint is added by PostgREST and it was introduced at a time where users manually typed table names, causing them to report malfunctions on typos. These hints are not that as necessary anymore so they're usually disabled via config[1] and will likely be dropped on a next version.

[1]: https://docs.postgrest.org/en/v16/references/configuration.h...

I can't believe someone actually made this by design

In practice it’s an absolutely stupid design. If you create tables without using their dashboard, like with an ORM or with SQL directly, it’s incredibly easy to have them not use RLS and be wide open to the public.

Taking a step back, the whole “query the database straight from the frontend” is a terrible design in general. For example, they still don’t offer rate limiting! Even if the tables data is secured, there’s nothing stopping someone from hammering the database directly with reads/writes until it overloads it, as there’s no application level rate limiting in the middle. Bonkers.

I agree. If AI agents are doing all the code anyway, as is the case with Lovable, just turn off the Data API entirely and access the DB from the backend only like a typical Postgres setup.

https://pocketbase.io/

True, but I've seen staff+ level developers get bit by this. What hope do vibe coders have?

Any tables created before the defaults put in place are of course still subject to the wide open defaults, because they would risk break existing users apps if they back-ported those.