How to add a real backend and database to a v0 app

To give a v0 app a real database, connect one through v0's integrations (Supabase, Neon or Upstash for data, Vercel Blob for files), let it add the connection settings as environment variables, and then ask v0 to replace the sample data in your components with server-side queries. The connection takes minutes. The part that needs care is what comes after: keeping secret keys off the browser, making sure each user only sees their own rows, and keeping a record of every change to the database structure.

This guide covers which database to pick, how to connect it, how to turn mock data into real data, and the checks to run before real users arrive.

Which database should I connect to v0?

v0's docs list one-click integrations with Upstash, Neon, Supabase and Vercel Blob. They solve different problems:

For a typical app with sign-ups, Supabase covers the most ground in one place. If you're weighing it against Firebase, see our Supabase vs Firebase comparison. Upstash and Blob usually sit next to a main database rather than replacing it.

How do I connect the database?

You can do it two ways:

1. From settings. Open the project menu (...), then Settings, then Integrations. Pick an existing store or click Create, which opens the Vercel Marketplace where you accept the provider's terms.
2. From the chat. Click the suggested action when v0 offers one, or simply ask v0 to add a database integration.

Either way, v0 says the integration creates an account on that service for you and adds the needed environment variables to your project. You'll find them under Settings, then Environment Variables, and you can manage the integration itself from the Vercel Marketplace.

New generations in that project can then use the database.

How do I turn mock data into real data?

A v0 prototype usually keeps its content in arrays at the top of a component: a list of tasks, products or customers typed straight into the code. Connecting a database doesn't change that. You have to ask for it, step by step. v0's own guidance is to build incrementally: UI first, then the data layer, then authentication.

A sequence that works well:

1. Describe the tables. "Create a projects table with id, name, owner_id and created_at, and a tasks table linked to projects."
2. Replace one screen at a time. "On the tasks page, load tasks from the database instead of the sample array. Keep the design."
3. Add writes. "Make the Add task form save to the database and refresh the list."
4. Then add sign-in, and connect every row to the user who owns it.

v0 defaults to Next.js, which lets the data code live next to the page in server components, server actions and API routes. That's where database calls belong.

Which keys must never reach the browser?

This is the most common security hole in v0 apps that move past the prototype. In Next.js, any environment variable whose name starts with NEXT_PUBLIC_ is bundled into the JavaScript that every visitor downloads. Everything else stays on the server.

• A public or anon key designed for browsers (such as Supabase's) can be public, as long as row-level security protects your tables.
• A service role key, a secret key or a full database connection string must never have the NEXT_PUBLIC_ prefix, and must only be used in server code.

Check the list under Settings, then Environment Variables, and search your code for each secret's name. If a secret shows up in a file that runs in the browser (a component marked "use client"), move that call into a server action or API route. Our guide on API keys exposed in the front end explains what to do if one already leaked.

How do I make sure users only see their own data?

Ask v0 to add authentication and "make sure users can only read and change their own tasks". Then verify it, because the screen hiding other people's rows is not the same as the database refusing to return them.

With Supabase, the protection belongs in row-level security policies on each table:

alter table tasks enable row level security;

create policy "Users read their own tasks"
on tasks for select
to authenticated
using ((select auth.uid()) = owner_id);

You need matching policies for insert, update and delete. Our Supabase RLS policy examples cover the common patterns. With Neon or another plain Postgres database, the same rule has to be enforced in your server code: every query filters by the signed-in user's ID, taken from the session, never from a value the browser sends.

To test it, create two accounts, add data with the first, sign in as the second and try to load the first user's records by changing an ID in the URL or the request.

How do I keep track of database changes?

v0's docs note that for SQL integrations it can generate and run SQL, including creating, altering and dropping tables. That's convenient in a prototype and risky with real data, because the change happens immediately and may leave no file behind.

Two habits keep this under control:

• Save every schema change as a migration file in the repository, even if v0 already ran it. Connect the project to GitHub (project menu, Settings, GitHub) so the files are versioned.
• Use a separate database for development and preview than for production. Vercel lets you set different environment variable values for Production, Preview and Development. Our guide on production vs preview environment variables walks through it.

Before you let v0 run a destructive statement (drop, alter ... type, delete) on a database with real users, take a backup.

Quick answers

Can v0 build a full-stack app with a database? Yes. v0 builds on Next.js and can connect Supabase, Neon or Upstash, write server-side queries and create tables.

Where does v0 store my database credentials? As environment variables in the project, under Settings, then Environment Variables. They're also visible on the linked Vercel project.

Is it safe to use the Supabase anon key in a v0 app? Yes, if row-level security is enabled with policies on every table. Without RLS, that key can read whatever the tables contain.

Should v0 run SQL directly on my production database? Not without a backup and a saved migration file. Use a separate database for development.

Need the backend checked before launch?

Connecting a database is quick; getting permissions, secrets and migrations right is where apps get into trouble. Our v0 to production service and Supabase security review cover exactly this. The free health check shows what is visible from outside, and you can read our guide on turning v0 components into a working app or contact us.