Cómo añadir una base de datos a tu app (sin perder datos después)

Para añadir una base de datos a tu app, elige una base de datos relacional gestionada (Postgres es la opción habitual), guarda su cadena de conexión en un secreto del servidor, crea una tabla por cada tipo de cosa que almacene tu app y haz que tu backend, nunca el navegador, lea y escriba en ella. Si construyes con un creador de apps con IA, normalmente basta con decir «guarda esto en una base de datos»: el agente configura las tablas y el código. Tu trabajo es describir bien los datos y comprobar que realmente se guardan.

Esta guía explica cuándo necesitas una base de datos, las opciones principales, cómo describir tus datos y los errores que provocan pérdida o filtración de datos.

Cuándo necesita tu app una base de datos

Necesitas una base de datos cuando tu app tiene que recordar algo después de cerrar la página, o compartir datos entre personas. Señales típicas:

• Los visitantes envían algo: un formulario, un registro, una reserva o un pedido
• Los usuarios tienen cuentas con contenido guardado propio
• Un administrador necesita ver o editar lo que han creado otros
• Quieres informes o recuentos a lo largo del tiempo

No la necesitas en una web estática donde todos ven el mismo contenido, como un portfolio o una landing page sencilla. Si no sabes qué es realmente una base de datos, lee primero qué es una base de datos.

Tus opciones

Para la mayoría de apps web pequeñas y medianas, una base de datos relacional como Postgres es la opción correcta por defecto. Se da bien con las relaciones (un cliente tiene muchos pedidos), mantiene los datos coherentes y te permite responder preguntas más adelante con SQL. Consulta qué es Postgres si quieres una explicación sencilla.

Describe tus datos antes de construir

Lo más útil que puedes hacer es escribir las cosas que almacena tu app y cómo se relacionan. No necesitas jerga de bases de datos. En una app de reservas, por ejemplo:

• Clientes: nombre, correo electrónico, teléfono
• Servicios: nombre, duración, precio
• Reservas: qué cliente, qué servicio, hora de inicio, estado (pendiente, confirmada, cancelada)

Son tres tablas. «Qué cliente» y «qué servicio» se convierten en enlaces (claves externas) entre ellas. Acertar con esto desde el principio importa mucho más que cualquier elección tecnológica, porque cambiar la forma de datos que ya tienen filas reales es más difícil que cambiar el diseño de una página.

Algunas reglas prácticas:

• Una tabla por cada tipo de cosa. No metas pedidos en una columna de texto dentro del cliente.
• Da a cada fila un ID y una fecha de creación. Los necesitarás más adelante.
• Usa tipos adecuados. Las fechas como fechas, el dinero en céntimos enteros o en un tipo decimal, no como texto.
• Marca los campos obligatorios como tales. Que sea la base de datos la que rechace los datos incorrectos, no solo el formulario.

Prompts de ejemplo

Empieza con una funcionalidad cada vez en lugar de volcar un esquema completo:

Añade una base de datos a esta app. Crea una tabla de reservas con nombre del cliente, correo electrónico, servicio, hora de inicio y estado (pendiente, confirmada, cancelada; por defecto pendiente). Guarda en ella los envíos del formulario de reserva, muestra un mensaje de éxito y añade una página de administración que liste las reservas de la más reciente a la más antigua.

Después, amplíala:

Añade una tabla de servicios (nombre, duración en minutos, precio en céntimos). Sustituye en las reservas el campo de servicio de texto libre por un enlace a servicios, y migra las reservas existentes sin borrarlas.

Y refuérzala:

Asegúrate de que todas las lecturas y escrituras en la base de datos se hacen en el servidor. El navegador nunca debe recibir la cadena de conexión. Valida el correo electrónico y la hora de inicio en el servidor antes de insertar.

Paso a paso

1. Haz la lista de tus datos como se ha explicado: cosas, campos y relaciones entre ellas.
2. Crea la base de datos. En un creador de apps con IA, pídelo en el chat. En otros sitios, crea una instancia de Postgres gestionada y copia su cadena de conexión.
3. Guarda la cadena de conexión como secreto (una variable de entorno en el servidor), nunca en el código. Consulta variables de entorno y secretos.
4. Crea las tablas. Usa migraciones (scripts versionados que modifican el esquema) para que los cambios sean repetibles y reversibles.
5. Construye las rutas del servidor que crean, leen, actualizan y borran filas (CRUD). El navegador llama a estas rutas; nunca habla directamente con la base de datos.
6. Conecta la interfaz a esas rutas: formularios que guardan, listas que cargan y estados vacíos cuando todavía no hay nada.
7. Prueba la persistencia. Envía algo, recarga la página, ábrela en otro navegador. Si los datos no están, no se han guardado en la base de datos.
8. Revisa los accesos. Entra con un segundo usuario y comprueba que no puedes ver ni editar los datos del primero.
9. Publica y vuelve a probar en la URL en vivo, ya que la app publicada puede usar una conexión distinta a la de la vista previa.

Errores habituales

• Guardar en el navegador y pensar que está guardado. localStorage parece funcionar hasta que alguien abre la app en otro dispositivo. Prueba siempre en un segundo navegador.
• Poner la cadena de conexión en el código del frontend. Cualquiera puede leer el código del frontend. Eso le da acceso a toda tu base de datos.
• No comprobar los accesos. «Muestra mis pedidos» debe filtrar por el usuario conectado en el servidor, no en la interfaz. Es el agujero de seguridad más común en apps creadas con IA; nuestra lista de seguridad para apps creadas con IA lo explica.
• Cambios destructivos en el esquema. Pedir «renombra la tabla» o «cambia la estructura» puede borrarla y volver a crearla. Cuando ya hay datos reales, di «migra las filas existentes, no borres nada».
• Guardar archivos dentro de la base de datos. Las imágenes y los PDF van en un almacenamiento de archivos, y en una tabla solo se guarda su URL o clave. Consulta cómo añadir subida de archivos.
• No tener copias de seguridad. Antes de tener clientes, sabe cómo hace copias tu plataforma y cómo restaurarlas.

Lista de comprobación

• Cada tipo de cosa tiene su propia tabla con un ID y una fecha de creación
• La base de datos aplica los campos obligatorios y los tipos
• La cadena de conexión solo está en secretos del servidor
• Todas las lecturas y escrituras pasan por rutas del servidor
• Cada usuario solo puede leer y modificar sus propias filas
• Los datos sobreviven a una recarga y aparecen en otro navegador
• Los cambios de esquema usan migraciones y conservan las filas existentes
• Sabes cómo funcionan las copias de seguridad y la restauración
• La app en vivo se ha probado después de publicar

Añadir una base de datos en Mythex

En Mythex, cada proyecto puede tener su propia base de datos Postgres dedicada, tanto en Free como en Pro. Normalmente no tienes que hacer clic en un botón de «conectar»: pide la base de datos en el chat («guarda los emails de la lista de espera en una base de datos») o escribe /database, y los datos de conexión se inyectan en el espacio de trabajo y en tu app publicada. En los ajustes del proyecto se ve si hay una base de datos activa.

La base de datos se duerme tras 5 minutos de inactividad y se despierta con la siguiente petición. El uso publicado se cobra solo por el tiempo que estuvo despierta, con el mismo saldo de créditos que usas para crear. Si añades una base de datos después de haber publicado, vuelve a publicar para que la app en vivo la use.

Consulta Database y la receta Build a CRUD app en la documentación. Para la parte de inicio de sesión de los datos por usuario, lee cómo añadir inicio de sesión a tu app.

Preguntas