This Supabase review is about the part of an AI-built app that the demo never shows. When a tool like Lovable or Bolt generates a task manager in an afternoon, the pretty screens are the easy half. The hard half is a database that remembers people, a login that works, files that stay private, and permissions that stop one customer reading another's rows. Supabase is the platform most AI app builders reach for to cover that half, and it is built around PostgreSQL.

Our angle is simple. Supabase is mature, well documented, and genuinely free to start on, which is exactly why it deserves a harder look than "an open Firebase". We checked every plan limit against the official pricing page, read the security documentation, and traced how the platform connects to Lovable, Bolt, and coding agents, then scored it with the ToolRadar weighted formula. The short version: the backend is strong, but the first working demo is not the finish line, and the security work that remains is yours.

Mahmoud Salamoun

Founder, ToolRadar · Reviewed Oct 15, 2026

Independent AI tools reviewer with a background in marketing and content, and hands-on daily experience directing AI tools like Gemini and ChatGPT for real work. This review is based on official documentation, published pricing, and verified third-party coverage — not a claim of hands-on testing of Supabase itself unless stated otherwise.

What You Actually Get

Here is a worked example, labeled as an architecture sketch and not a test. Say an agent builds you a paid task app. The tool writes the screens. Supabase stores users and tasks, Auth handles login, and row-level policies decide which person sees which task. An Edge Function handles anything needing a secret. A separate payment provider collects subscriptions, and your app records who is subscribed. Supabase does not give you a billing system for free; that integration is yours to build and test.

Pricing: What the Free Plan Really Covers

There is a genuine free plan, and for a prototype it is generous. The catch is in the details around it: two active projects, a database of 500 MB, and projects that pause after a week of inactivity. Prices below come from the official page.

Also note what the plan does not cover: the AI builder you use (Lovable, Bolt and others charge separately), calls to a language model, frontend hosting, email delivery, and the payment gateway. Those are all separate line items, so "free to start" is true while "free to run a business" is not.

Where Supabase Sits in Lovable, Bolt, and Agent Workflows

It is tempting to say every AI builder "runs on Supabase", but the picture is more careful than that.

Lovable. Lovable offers two backends: Lovable Cloud, which it manages, or a Supabase project you own. Supabase's own troubleshooting guide spells out the difference. A Lovable Cloud project does not appear in your Supabase Dashboard, you get no service role key, and you get no direct database URL. A project you connected yourself shows in your dashboard with key and database access. If you plan to take your app elsewhere later, that distinction matters on day one. Our Lovable review covers the builder side.

Bolt. Bolt's Bolt Cloud announcement names Supabase and Netlify as partners and lists databases, authentication, file storage and serverless functions as features then marked "coming soon" in a private beta. The article does not say Bolt's database is Supabase, and it does not explain how an existing Supabase project relates to Bolt Cloud, so we will not guess. If you use Bolt, check which backend your project actually uses; our Bolt.new review and the v0 vs Bolt vs Cursor comparison help with the frontend side.

Coding agents. Here the connection is direct. Supabase's MCP server lets an agent query data, run migrations, and deploy Edge Functions against your project. That power comes with a warning from the docs themselves: prompt injection is the main risk. Hidden instructions inside user content, a support ticket for instance, could trick the model into running harmful queries. Supabase wraps SQL results with defensive text but calls it "not foolproof". Its recommendations are to keep manual approval on, scope the server to one project, use read-only mode for unattended work, avoid pointing it at production data, and never hand the server to your customers. If you run agents like these, our comparison of Claude Code, Cursor and Copilot and the OpenCode review are the right companions.

So Supabase is rarely a rival to the builder. It is the layer underneath, and a reason a separate review makes sense even when a builder bundles its own backend.

Is Supabase Good for AI and RAG Apps?

For apps that search your own data, yes, and it keeps everything in one database. Supabase's AI documentation covers storing embeddings with pgvector, semantic search by meaning, keyword search, and hybrid search that combines both. Edge Functions can generate embeddings with open-source models or call a hosted model API, and the docs list integrations with OpenAI, Hugging Face, LangChain, LlamaIndex, and Amazon Bedrock.

One honest caveat. The main AI page does not describe retrieval-augmented generation in depth; it points to a "RAG with Permissions" guide and several examples. In practice, you would store documents and embeddings in Postgres, retrieve the relevant passages for a question, and send them to a model. The embeddings and the answers may come from an outside provider, which adds a cost Supabase's price does not include. The permissions angle is the interesting part: your row-level rules can decide whose documents a search is allowed to return.

What Is Still Alpha: The October 2026 Announcements

On October 2, 2026, Supabase published its "Select" announcements, aimed squarely at agent-driven development. They are exciting and also uneven in maturity, so read the labels.

• Agent-ready local development: local Supabase running as native processes without Docker, one instance per directory. The post says: "It's in alpha today, off by default."
• Declarative Schemas 2.0: an agent edits SQL schema files in your repository and the CLI's new diff engine, pg-delta, generates the migration. New projects from supabase init use it by default. The post gives no status label.
• Config in code: auth providers, API limits and storage buckets can live in config.toml, with supabase config pull to bring dashboard changes back. No status label given.
• Supabase Compute: long-running services and agents in the same project as your database. Status: "private alpha", with a waitlist, so it is not generally available.
• An MCP server for your own app: distinct from the official MCP server. It lets your users' agents act inside your app as the signed-in user, with your row-level policies still deciding what they can reach. It requires asymmetric signing keys and the Supabase Auth OAuth server.

Treat these as a direction of travel, not features to build a business on this week. The sensible reading is that schema-in-Git and config-in-code are the practical wins, because they make database changes reviewable the way code is.

The Real Risk: An AI-Generated App That Is Not Secure

This is the section to read twice. Supabase exposes your tables through an API, and Row Level Security (RLS) is what decides which rows each user can see. Its documentation is blunt: a table without RLS is readable and writable by any role with a grant on it. Once RLS is enabled, no data is accessible through the API until you write policies, and policies do not remove grants, so revoking them is a separate step.

Three mistakes recur.

• Forgetting RLS. The table works in your demo and quietly serves everyone's data.
• Exposing a secret key. A secret key reaches the database through the service_role Postgres role, which bypasses RLS. The docs say never to use it in the browser or expose it to customers. It bypasses policies only when the request carries no user token; with a user token, that user's policies apply.
• Trusting generated policies blindly. A policy can look right and still miss an operation or a role. The docs recommend writing a test per table covering allow and deny cases for select, insert, update and delete, for both anonymous and signed-in roles.

How common is the problem? Third-party figures exist, with caveats. A January 2026 scan reported on Hacker News examined 20,052 URLs from five indie launch directories and claimed an 11.04% exposure rate, including 2,325 critical exposures mostly from service_role keys; that is the scanner's own report, not an audited study. A separate write-up of researcher Matt Palmer's CVE-2025-48757 finding says 170 of 1,645 Lovable-built apps, about 10.3%, exposed data because RLS was off, per BuildMVPFast. A security vendor's analysis adds that the root cause was insecure defaults in the builder and not a flaw in Postgres, while some parties argue customers still own correct RLS setup. Those are different parties blaming different layers, and the reasonable takeaway is that responsibility is shared and you cannot assume the tool did it.

The same lesson applies to the agent layer. Our piece on security holes in AI agents covers why giving a model database access deserves the same caution.

Pros and Cons

How It Compares With Firebase, Appwrite, and Convex

These alternatives are for comparison by need, not the outcome of a head-to-head benchmark. We used each vendor's own pricing page; where a page did not show plan details, we say so instead of filling the gap.

The practical split is about data shape and team. Choose Supabase when relational data and SQL are a natural fit, Firebase when you want Google's stack and document storage, Convex when a reactive developer experience is the point, and Appwrite when its model of per-database compute suits you. For deployment alongside a backend, see our look at Kuberns. Always confirm current limits on each vendor's page, because Appwrite's plan table did not load for us.

💡 What Developers Said on Hacker News

The first comment explains a distinction that trips beginners: the public anon key is supposed to ship in browser code, and what must never ship is the secret key. The second one names the real weakness, which is that the people most likely to leave RLS off are the least likely to run a scanner. The same thread also drew a question about how the scanner decided a project counted as "vibe coded", a fair challenge to its headline number. We read both comments as support for the earlier point: the platform documents the rules clearly, but the audience arriving through AI builders often has not read them.

Who Should Use Supabase

Expert Editorial Opinion

Final Verdict

Final score = (9.0 × 0.30) + (8.4 × 0.25) + (9.0 × 0.20) + (9.0 × 0.15) + (7.8 × 0.10) = 2.70 + 2.10 + 1.80 + 1.35 + 0.78 = 8.73.

❓ Frequently Asked Questions

🔗 Related ToolRadar Reviews