Supabase vs Firebase for vibe coders: common production errors

What we are not claiming

This is not a popularity contest and not a speed test. Neither vendor publishes a count of production incidents for AI-built apps. Below are production errors their own docs describe, and how the failure looks to someone who didn't write the rules.

The error that looks like "no data"

Supabase. Row Level Security can hide rows instead of throwing. If RLS is on and no policy matches, a select returns an empty array and no error. Supabase's troubleshooting guide says that, and also says a filter with no matching rows looks the same. A missing table grant is different: Postgres raises 42501 permission denied before the policy runs. An insert that fails the policy raises new row violates row-level security policy.

Firebase Firestore. Security rules are not filters. If a query could return a document the client is not allowed to read, the entire request fails, even when every document that exists today would have been allowed. The client sees a permission-denied error, not a shorter list. The query has to include the same constraint the rule checks, such as author == request.auth.uid.

So a "blank screen" on Supabase is often an empty data array. The same mistake on Firestore is usually a failed request.

Signed-out users

Firestore rules see request.auth as null when nobody is signed in. A rule of request.auth != null then denies the read. Supabase's auth.uid() is null in that same situation, and a policy written TO authenticated does not apply to the anon key. Both products are working as documented. The app has to send a signed-in session, not only a public API key.

Firebase also documents a hard cap on get() and exists() calls inside rules. Going over the cap is permission denied, even if the logic would have allowed the document.

Keys and redirects

Supabase is deprecating the long-lived anon and service_role JWTs by the end of 2026, in favor of sb_publishable_… and sb_secret_…. The secret key bypasses RLS and is rejected from browsers. The publishable key is the one that belongs in the app. See Invalid JWT after the new keys.

Supabase Auth will send users to the Site URL after login. If that is still http://localhost:3000, production login looks broken. Allowed redirect URLs have to include the live origin.

Firebase Auth has its own authorized-domain list for OAuth handlers. This page does not invent a click-path for it. Use the Firebase Auth docs for your sign-in method before copying a URL from the preview.

Which one should a vibe coder pick?

The docs don't answer that with a score. They do tell you what the first production bug will look like. If the builder already handed you a Supabase project, start with RLS and the Site URL. If it handed you Firestore, start with rules that match the query, because a too-broad query fails closed.

Sources

• https://supabase.com/docs/guides/troubleshooting/why-is-my-select-returning-an-empty-data-array-and-i-have-data-in-the-table-xvOPgx (opens in a new tab)
• https://supabase.com/docs/guides/database/postgres/row-level-security (opens in a new tab)
• https://supabase.com/docs/guides/getting-started/api-keys (opens in a new tab)
• https://firebase.google.com/docs/firestore/security/rules-query (opens in a new tab)
• https://firebase.google.com/docs/rules/rules-and-auth (opens in a new tab)
• https://firebase.google.com/docs/rules/rules-behavior (opens in a new tab)