Base de datos de Replit en producción: desarrollo y respaldos
Cómo separa Replit la base de desarrollo de la de producción, qué pasa con tu esquema al publicar, cómo funcionan los restores y cómo cuidar los datos reales.
Read in English →
Replit le da a cada app una base de datos de desarrollo, y al publicar crea (o usa) una base de producción aparte para tus usuarios reales. Agent puede modificar la de desarrollo pero no la de producción; al publicar, los cambios de estructura, como tablas y columnas nuevas, se aplican a producción, y tus datos se quedan donde están. Esa separación te protege, siempre que sepas qué base estás mirando y tengas un plan para respaldos y para los cambios de esquema delicados.
En esta guía vemos cómo se relacionan las dos bases, cómo saber qué configuración tiene tu app, qué cuidar cuando cambia el esquema y cómo funcionan los restores.
¿Qué diferencia hay entre la base de desarrollo y la de producción?
| Base de desarrollo | Base de producción | |
|---|---|---|
| Cuándo se crea | Con cada app | Al publicar |
| Quién la modifica | Tú y Agent | Tu app en vivo (Agent no puede tocarla) |
| Qué debe contener | Cuentas de prueba, datos falsos, experimentos | Usuarios y registros reales |
| Cobro | Incluida | Se cobra por uso |
En la base de desarrollo Agent crea tablas, agrega columnas y llena filas de ejemplo mientras construye. En la de producción vive lo que escriben tus clientes. Piensa en ellas como dos lugares distintos con trabajos distintos.
Un detalle práctico de la documentación de Replit: el cómputo de una base se deja de cobrar tras cinco minutos sin actividad y se reanuda con la siguiente consulta, así que una base de producción sin uso no acumula cargos de cómputo.
¿Cómo sé qué configuración tiene mi app?
Replit pasó sus bases de datos a infraestructura propia (llamada Helium) y actualizó las apps antiguas que usaban Neon. Para revisarlo, abre Settings en la herramienta Database y mira DATABASE_URL:
- Si el host contiene
helium, estás en la configuración actual, y la base de producción se crea sola al publicar (cuando la de desarrollo tiene datos). - Si contiene
neon.tech, es la configuración antigua. Ahí activas tú Create production database en los ajustes de publicación, con una opción para copiar los datos de desarrollo.
Si copias datos de desarrollo, elige con cuidado. Las cuentas de prueba con contraseñas débiles, los registros a medias y los pedidos de ejemplo terminan delante de usuarios reales.
Las apps que se crearon como fork o remix de proyectos viejos a veces compartían una misma base entre copias. Replit retiró esas bases compartidas en 2026; si tu app estaba en ese caso, los pasos de migración están en su documentación.
¿Qué le pasa a mi esquema cuando publico?
Al publicar, Replit toma los cambios de estructura hechos en desarrollo (tablas y columnas agregadas o eliminadas) y los aplica a producción. Agregar cosas suele ser seguro. Esto no:
- Eliminar una columna que el código todavía lee. La app en vivo se rompe en cuanto consulta el campo que ya no existe.
- Renombrar una tabla o columna. Las herramientas que comparan esquemas pueden interpretar un cambio de nombre como "borrar una y crear otra", y los datos de la vieja no se mueven.
- Cambiar el tipo de dato, por ejemplo de texto a número, cuando las filas existentes no se convierten bien.
- Agregar un campo obligatorio sin valor por defecto. Las filas que ya existen no tienen valor para él.
- Endurecer restricciones, como volver único un campo que ya tiene duplicados.
Replit advierte que publicar puede causar una breve caída, y recomienda usar una vista previa del despliegue para probar los cambios de base de datos antes de que lleguen a los usuarios.
Una forma más segura de hacer un cambio delicado
- Agrega la columna nueva junto a la vieja, con un valor por defecto.
- Publica y copia los valores existentes a la columna nueva con una actualización única.
- Cambia el código para que lea la columna nueva y vuelve a publicar.
- Cuando nada lea la columna vieja, elimínala en una publicación posterior.
Son tres publicaciones en vez de una, pero ningún paso puede perder datos. Si Agent propone renombrar en un solo paso una tabla con datos reales, detente y pídele esta secuencia.
¿Cómo veo o corrijo datos en producción?
Abre la herramienta Database, selecciona la base de producción, entra a My Data y activa Edit. Úsalo para correcciones pequeñas, como un error en el nombre de un cliente. Para algo más grande, escribe el cambio como una sentencia SQL, pruébalo antes en la base de desarrollo y guarda una copia de lo que ejecutaste.
Nunca conectes la app que estás desarrollando a la base de producción para "probar con datos reales". Así es como una prueba termina borrando registros de verdad.
¿Cómo funcionan los respaldos y los restores en Replit?
Hay dos formas distintas de "volver atrás", y confundirlas genera mucho susto:
- Checkpoints y rollbacks devuelven el código de la app (y el estado de desarrollo) a un punto anterior. Según la documentación de recuperación de datos de Replit, hacer rollback no restaura tu base de producción.
- Point-in-time restore devuelve la base de producción a un momento que eliges. Abres los ajustes de restauración de la base, eliges la hora y confirmas. Al momento de escribir esto, Replit indica 7 días de historial en el plan Core y 28 días en Pro y Teams.
Si una mala publicación rompió el código y además dañó datos, necesitas las dos cosas: volver el código a un checkpoint y republicar, y restaurar la base a justo antes del daño.
Si eliminas una base por error, Replit la conserva en borrado temporal durante siete días, y en ese plazo soporte puede ayudarte a recuperarla. Después se borra para siempre.
¿Conviene tener mis propios respaldos?
Si tu app tiene clientes que pagan, sí. Los restores de la plataforma cubren errores dentro del periodo de retención; no te sirven si necesitas datos de hace dos meses, si pierdes acceso a la cuenta o si decides cambiar de hosting. Las bases de Replit usan PostgreSQL 16, así que las herramientas estándar de Postgres sirven. Revisa la pestaña Settings de la base de producción para ver los datos de conexión y si tu configuración permite conectarse desde fuera de la app.
Una rutina sencilla:
- Exporta la base de producción con una frecuencia fija (cada semana como mínimo, a diario si los datos cambian mucho).
- Guarda las exportaciones fuera de Replit, con acceso solo para quien lo necesita.
- Cada pocos meses, restaura una exportación en una base de prueba y abre la app contra ella. Un respaldo que nunca restauraste es una suposición.
Nuestra guía de respaldos de Supabase cubre los mismos hábitos para cuando la base termina en otro lugar, y en cómo sacar tu app de Replit explicamos cómo se mueven los datos si das ese paso.
Respuestas rápidas
¿Replit Agent modifica mis datos de producción? No. Agent trabaja sobre la base de desarrollo. Los cambios de estructura llegan a producción al publicar; tus filas de producción no se reemplazan con las de desarrollo.
¿Puedo restaurar mi base de Replit a ayer? Sí, con point-in-time restore sobre la base de producción, dentro del periodo de retención de tu plan. Volver a un checkpoint por sí solo no lo hace.
¿Por qué mi app en vivo no tiene los datos que veo en la herramienta Database? Probablemente estás mirando la base de desarrollo. Selecciona la de producción en la herramienta Database.
¿Es seguro renombrar una columna en una app de Replit en vivo? No en un solo paso. Agrega la columna nueva, copia los datos, cambia el código y elimina la vieja más adelante.
¿Quieres que alguien revise cómo guardas tus datos?
Un cambio de esquema equivocado es de los pocos errores que no se deshacen con un prompt. Si tu app ya tiene usuarios, nuestro servicio para arreglar apps de Replit incluye revisar cómo están montados los datos, los Secrets y la publicación. También puedes empezar por la revisión gratuita de tu app, leer sobre entornos de pruebas para apps pequeñas o escribirnos.
