Cómo agregar un backend y una base de datos a tu app de v0

Para darle una base de datos real a una app de v0, conéctala desde las integraciones de v0 (Supabase, Neon o Upstash para datos, Vercel Blob para archivos), deja que agregue la configuración de conexión como variables de entorno y después pídele a v0 que reemplace los datos de ejemplo de tus componentes por consultas desde el servidor. Conectar toma minutos. Lo que requiere cuidado viene después: mantener las claves secretas fuera del navegador, asegurarte de que cada usuario vea solo sus filas y llevar registro de cada cambio en la estructura de la base.

En esta guía vemos qué base elegir, cómo conectarla, cómo pasar de datos falsos a datos reales y qué revisar antes de que lleguen usuarios de verdad.

¿Qué base de datos conecto a v0?

La documentación de v0 menciona integraciones de un clic con Upstash, Neon, Supabase y Vercel Blob. Resuelven problemas distintos:

Para una app típica con registro de usuarios, Supabase cubre más cosas en un solo lugar. Si la estás comparando con Firebase, revisa nuestra guía Supabase o Firebase para tu app. Upstash y Blob suelen acompañar a una base principal, no reemplazarla.

¿Cómo conecto la base de datos?

Hay dos caminos:

1. Desde los ajustes. Abre el menú del proyecto (...), luego Settings y después Integrations. Elige un almacén que ya tengas o haz clic en Create, que abre el Vercel Marketplace para aceptar los términos del proveedor.
2. Desde el chat. Haz clic en la acción sugerida cuando v0 la ofrezca, o pídele directamente que agregue una integración de base de datos.

En los dos casos, según v0, la integración te crea una cuenta en ese servicio y agrega las variables de entorno necesarias a tu proyecto. Las encuentras en Settings, luego Environment Variables, y la integración en sí se administra desde el Vercel Marketplace.

A partir de ahí, las nuevas generaciones de ese proyecto pueden usar la base.

¿Cómo paso de datos de ejemplo a datos reales?

Un prototipo de v0 suele guardar su contenido en arreglos al inicio de un componente: una lista de tareas, productos o clientes escrita directo en el código. Conectar una base no cambia eso. Hay que pedirlo, paso a paso. La propia guía de v0 recomienda avanzar de a poco: primero la interfaz, después la capa de datos y luego la autenticación.

Una secuencia que funciona bien:

1. Describe las tablas. "Crea una tabla projects con id, name, owner_id y created_at, y una tabla tasks vinculada a projects."
2. Cambia una pantalla a la vez. "En la página de tareas, carga las tareas desde la base en vez del arreglo de ejemplo. Mantén el diseño."
3. Agrega las escrituras. "Haz que el formulario de nueva tarea guarde en la base y actualice la lista."
4. Después agrega el inicio de sesión y vincula cada fila al usuario dueño.

v0 usa Next.js por defecto, lo que permite que el código de datos viva junto a la página en server components, server actions y rutas de API. Ahí es donde deben ir las llamadas a la base.

¿Qué claves nunca deben llegar al navegador?

Es el agujero de seguridad más común en las apps de v0 que pasan del prototipo. En Next.js, toda variable de entorno cuyo nombre empieza con NEXT_PUBLIC_ se incluye en el JavaScript que descarga cada visitante. Las demás se quedan en el servidor.

• Una clave pública o anon pensada para el navegador (como la de Supabase) puede ser pública, siempre que row-level security proteja tus tablas.
• Una service role key, una clave secreta o una cadena de conexión completa nunca debe llevar el prefijo NEXT_PUBLIC_ y solo debe usarse en código de servidor.

Revisa la lista en Settings, luego Environment Variables, y busca el nombre de cada secreto en tu código. Si un secreto aparece en un archivo que corre en el navegador (un componente marcado con "use client"), pasa esa llamada a una server action o a una ruta de API. Si alguna ya se filtró, en la guía sobre claves de API expuestas en el frontend te decimos qué hacer.

¿Cómo me aseguro de que cada usuario vea solo sus datos?

Pídele a v0 que agregue autenticación y que "los usuarios solo puedan ver y modificar sus propias tareas". Después compruébalo, porque que la pantalla oculte las filas ajenas no es lo mismo que la base se niegue a devolverlas.

Con Supabase, esa protección va en políticas de row-level security en cada tabla:

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);

Necesitas políticas equivalentes para insert, update y delete. En nuestros ejemplos de políticas RLS en Supabase están los casos más comunes. Con Neon u otra base Postgres sin RLS configurado, la misma regla tiene que cumplirse en tu código de servidor: cada consulta filtra por el ID del usuario que inició sesión, tomado de la sesión y nunca de un valor que manda el navegador.

Para probarlo, crea dos cuentas, carga datos con la primera, entra con la segunda e intenta traer los registros de la primera cambiando un ID en la URL o en la petición.

¿Cómo llevo el control de los cambios en la base?

La documentación de v0 aclara que, con integraciones SQL, puede generar y ejecutar SQL, incluido crear, modificar y eliminar tablas. Es cómodo en un prototipo y arriesgado con datos reales, porque el cambio ocurre al instante y puede no dejar ningún archivo.

Dos hábitos lo mantienen bajo control:

• Guarda cada cambio de esquema como un archivo de migración en el repositorio, aunque v0 ya lo haya ejecutado. Conecta el proyecto a GitHub (menú del proyecto, Settings, GitHub) para que los archivos queden versionados.
• Usa una base distinta para desarrollo y vistas previas que para producción. Vercel permite valores diferentes de las variables de entorno para Production, Preview y Development. Lo explicamos en la guía de variables de entorno en producción y preview.

Antes de dejar que v0 ejecute una sentencia destructiva (drop, alter ... type, delete) sobre una base con usuarios reales, haz un respaldo.

Respuestas rápidas

¿v0 puede crear una app completa con base de datos? Sí. v0 trabaja sobre Next.js y puede conectar Supabase, Neon o Upstash, escribir consultas en el servidor y crear tablas.

¿Dónde guarda v0 las credenciales de mi base? Como variables de entorno del proyecto, en Settings, luego Environment Variables. También se ven en el proyecto de Vercel vinculado.

¿Es seguro usar la clave anon de Supabase en una app de v0? Sí, si row-level security está activado con políticas en todas las tablas. Sin RLS, esa clave puede leer todo lo que haya en ellas.

¿Debería v0 ejecutar SQL directo en mi base de producción? No sin un respaldo y un archivo de migración guardado. Usa una base aparte para desarrollo.

¿Quieres revisar el backend antes del lanzamiento?

Conectar una base es rápido; dejar bien los permisos, los secretos y las migraciones es donde las apps se complican. Nuestros servicios para llevar tu app de v0 a producción y de revisión de seguridad de Supabase cubren justo esto. La revisión gratuita de tu app muestra lo que se ve desde afuera, y también puedes leer cómo convertir componentes de v0 en una app real o escribirnos.