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 lado del servidor, crea una tabla por cada tipo de cosa que guarde 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” y el agente crea las tablas y el código; tu trabajo es describir los datos con claridad y comprobar que de verdad se conservan.

Esta guía explica cuándo necesitas una base de datos, las opciones principales, cómo describir tus datos y los errores que causan pérdidas o fugas 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, un pedido
• Los usuarios tienen cuentas con contenido propio guardado
• Un administrador necesita ver o editar lo que crearon otros
• Quieres informes o recuentos a lo largo del tiempo

No la necesitas para una web estática donde todos ven el mismo contenido, como un portafolio o una landing sencilla. Si no tienes claro qué es una base de datos, lee primero qué es una base de datos.

Tus opciones

Para la mayoría de las webs y apps pequeñas o medianas, una base de datos relacional como Postgres es la opción adecuada por defecto. Se da bien con las relaciones (un cliente tiene muchos pedidos), mantiene los datos consistentes y te permite responder preguntas después con SQL. Consulta qué es Postgres para una explicación sencilla.

Describe tus datos antes de construir

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

• 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 registros 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 los pedidos en un campo 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 como obligatorios los campos requeridos. Que sea la base de datos quien rechace los datos incorrectos, no solo el formulario.

Prompts de ejemplo

Empieza con una funcionalidad a la 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 el campo de texto libre del servicio en las reservas por un enlace a servicios, y migra las reservas existentes sin borrar ninguna.

Y refuérzala:

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

Paso a paso

1. Enumera tus datos como se indicó arriba: cosas, campos y enlaces entre ellas.
2. Crea la base de datos. En un creador de apps con IA, pídelo en el chat. En otros entornos, 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, es decir, scripts versionados que cambian 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 se 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 guardaron en la base de datos.
8. Comprueba los accesos. Entra con un segundo usuario y confirma 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 creer 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 les da acceso a toda tu base de datos.
• No tener comprobaciones de acceso. “Mostrar 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 comprobación de seguridad lo cubre.
• Cambios destructivos en el esquema. Pedir “renombrar la tabla” o “cambiar la estructura” puede eliminarla y volver a crearla. Cuando ya hay datos reales, di “migra las filas existentes, no borres nada”.
• Guardar archivos en la base de datos. Las imágenes y los PDF pertenecen al almacenamiento de archivos, y en una tabla solo debe guardarse su URL o clave. Consulta cómo añadir subida de archivos.
• No tener copias de seguridad. Antes de tener clientes, averigua 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 vive 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 pulsar un botón aparte de “conectar”: pídelo en el chat (“guarda los correos 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. Los ajustes del proyecto muestran 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 por el tiempo en 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 Base de datos y la receta Crear una app CRUD 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