Lovable and Bolt build the frontend in minutes — but an app that remembers nothing between sessions isn’t an app, it’s a prototype. Supabase is the layer that turns the prototype into a real product: managed PostgreSQL database, authentication with dozens of providers, file storage, Row Level Security for data protection. All free up to 500 MB of database and 50,000 monthly active users. Ninth installment of the Digital Stack 2026 series.
There’s a precise moment when vibe coding stops being a game and becomes a real project. It usually coincides with the first question: “where do I actually store the data?”. Lovable generates a beautiful React interface. Bolt builds a working app with authentication and filters. But without a backend, every refresh wipes everything — no registered users, no persistent data, no saved sessions.
Supabase is the answer to that question. And — not a minor detail — it’s open source, self-hostable, and has a free plan that for the vast majority of personal projects and MVPs never runs out.
What Supabase Is: the Backend You Don’t Have to Program
Supabase is often described as “open-source Firebase”. The definition is convenient but reductive. Firebase is a proprietary Google ecosystem with a NoSQL database (Firestore). Supabase uses PostgreSQL — the most widely used relational database in the world — and exposes it through auto-generated REST and GraphQL APIs. If you can write a basic SQL query, you already know how to use Supabase. If you can’t, the visual table editor covers 90% of use cases without touching a line of code.
The dashboard below is from a real project — “demo-flowygo” — created in a Supabase Free account. The status panel shows the entire stack of active and healthy services: Database, PostgREST (the automatic APIs), Auth, Realtime, Storage, Edge Functions. Six backend services, all operational, all managed, without writing a single line of server configuration. Region: West EU (Ireland) — servers in Europe, directly relevant for GDPR compliance.
Integration with Vibe Coding Tools: Bolt and Lovable
Both main vibe coding tools integrate Supabase natively — but with different approaches that are worth understanding before starting a project.
Bolt: Connect to Your Own Supabase Account
Bolt offers the most control over the integration. By default it creates an internally managed database, but from Project Settings → Database → Advanced you can connect an existing Supabase project from your own account. The screenshot below shows exactly this option: “Connect to an existing database — Connect to a different Supabase project to manage your data”. The Connect button opens a modal asking for the project URL and API key — both available in Supabase under Project Settings → API.
The orange warning is honest and important: connecting an external Supabase database to an already-existing Bolt project can cause misalignments between the generated code and the new database schema. The correct practice is to connect Supabase before you start building — not after. That way, the code Bolt generates is written already knowing the target database.
Lovable: Supabase Integrated but Separately Managed
Lovable works differently: when you generate an app with authentication or database functionality, it automatically creates a Supabase instance dedicated to that project — accessible from Lovable’s internal panel but not visible directly in the user’s personal Supabase account. It’s a simpler approach (zero configuration), but less transparent: you don’t have direct access to tables, RLS policies, or the SQL editor through the standard Supabase dashboard.
The good news is that Lovable still exposes an internal Supabase panel with Table Editor, SQL Editor, and policy visualization — functionally equivalent, even if it’s not your account. For the vast majority of projects, this-is-fine. If you need full access to the Supabase database with your own account — for example to connect it to Grafana, export data to other systems, or use advanced Row Level Security — the route is to use Bolt with a connection to your personal Supabase, as shown in the previous screenshot.
What Gets Built in Practice: Bolt’s Todo App with Supabase Auth
The screenshot below is the result of a prompt sent to Bolt: “Create a todo app with user authentication via Supabase Auth — email and password login, task management with priority and due date, dashboard with total/active/completed counters”. Generation time: approximately 90 seconds.
The app is called Taskflow. In the top right you can see the logged-in user’s email ([email protected]) with a Sign Out button — the authentication is real, managed by Supabase Auth. The three cards at the top show the counters: 1 Total, 1 Active, 0 Done. The task in the list — “Project design”, medium priority, due May 21 — is persisted in the Supabase database: close and reopen the browser, it’s still there. In the left panel, the code generated by Bolt explicitly describes the technical choice: Supabase Auth authentication with React context, login/register form with tab switching.
Row Level Security: The Feature That Separates a Prototype from a Secure Product
This is the most important concept in the article — and probably the least intuitive for anyone coming from a no-code background. When Bolt or Lovable generate an app with a Supabase database, tables are created with Row Level Security (RLS) enabled by default. But what does that actually mean in practice?
Without RLS, anyone who knows your Supabase project URL and the public API key can read all data from all users. With RLS active, each user can only access their own rows — those where the user_id column matches the authenticated user’s ID. The check happens at the database level, not the application level: even if the frontend has a bug, the database never returns another user’s data.
The Four Policies Bolt Generates Automatically
The screenshot below shows the Authentication → Policies panel of the Supabase project connected to Bolt, filtered on the todos table. Four policies automatically generated by the AI, one for each CRUD operation:
- Users can delete own todos — DELETE command — applied to: authenticated
- Users can insert own todos — INSERT command — applied to: authenticated
- Users can update own todos — UPDATE command — applied to: authenticated
- Users can view own todos — SELECT command — applied to: authenticated
All four apply the same base logic: the operation is allowed only if the user is authenticated and the row’s user_id matches the current session ID. The banner at the top also highlights the option to auto-enable RLS on all new tables — a best practice that Bolt activates by default. The Create policy button lets you add custom SQL rules for more complex cases: for example, allowing public read access to some rows while restricting write access to the owner only.
Free Plan vs Paid Plans: When Supabase Is Truly Free
The Supabase Free plan includes: 500 MB of PostgreSQL database, 1 GB of file storage, 50,000 monthly active users for authentication, 500,000 Edge Function invocations per month, 2 GB of egress bandwidth. For an MVP, a personal project, or an internal business tool with a few dozen active users, the free plan never runs out in practice.
Limits to keep in mind: free instances are paused after 7 days of inactivity (the first access after the pause reactivates them automatically in about 30 seconds). The compute tier is NANO — sufficient for development and small volumes, not for applications with hundreds of simultaneous queries. For those cases the Pro plan starts at $25/month with dedicated compute and no automatic pausing.
Supabase vs Firebase: a Quick Compass
Firebase is the right choice if your stack is entirely Google (Google Auth, Firestore, Firebase Hosting, Analytics) and you prefer NoSQL document-oriented databases. Supabase is the better choice if you need relationships between tables, complex SQL queries, standard data export, open source with self-hosting capability, or if GDPR is a priority and you want servers in Europe. For vibe coding tools — Bolt, Lovable, Cursor — Supabase has become the de facto standard precisely because PostgreSQL is the database that AI models know best and generate most reliably.
Up Next: Apache Kafka Part 1
With Supabase we close the applications block: Forms for data collection, Sheets for analysis, Neo4j for relationships, Claude Code and Design for building products, Grafana for monitoring, RAG for enterprise chatbots, multimodal AI for documents, Sentiment Analysis for text, Supabase for the backend. Next week we enter advanced data engineering: Apache Kafka, the distributed nervous system of Netflix, LinkedIn, and Uber. How topics, partitions, and consumer groups work — and why it’s not “just a message broker”. Supabase for vibe-coded apps: the backend that turns a prototype into a product. The next step is handling data at scale.
