Por qué cada app de Mythex tiene su propia base de datos

Cuando una app que construyes en Mythex necesita guardar datos (registros, reservas, pedidos), Mythex da a ese proyecto su propia base de datos Postgres. No una tabla dentro de una base de datos compartida, ni un esquema junto al de otra persona: una base de datos separada, creada bajo demanda, que entra en reposo cuando nadie la usa. Esto explica por qué la construimos así y qué cuesta.

Qué obtienes

Cuando pides datos («guarda los correos de la lista de espera», «almacena las reservas») o usas el comando /database, Mythex:

• crea una base de datos Postgres dedicada para el proyecto (actualmente Postgres 17),
• inyecta los datos de conexión en tu espacio de trabajo y en tu app publicada como variables de entorno, para que nunca aparezcan en tu código, y
• permite que el agente cree tablas y lea y escriba datos por ti.

La misma base de datos la usan la vista previa en directo y la app publicada. Entra en reposo tras 5 minutos inactiva y despierta con la siguiente consulta. Las bases de datos nuevas empiezan pequeñas y pueden escalar bajo carga, con un techo para que una consulta descontrolada no crezca sin límite. Más información en la documentación de bases de datos.

¿Por qué no una gran base de datos compartida?

Una base de datos compartida con una columna que indique a qué app pertenece cada fila es más barata de ejecutar y más sencilla de operar. No la elegimos por cuatro razones.

1. Aislamiento en el que no tienes que confiar

El código escrito por IA comete errores. En una base de datos compartida, un solo WHERE app_id = … olvidado en la consulta de una app podría leer o sobrescribir los datos de otro cliente. Con una base de datos por app, no hay datos de ningún otro cliente al alcance: un fallo se queda dentro de su propia app.

2. Es un Postgres real, no una capa propietaria

Tu app habla con Postgres estándar mediante una cadena de conexión normal. Cualquier biblioteca, ORM o herramienta que funcione con Postgres funciona aquí. Si exportas tu proyecto para ejecutarlo en otro sitio, espera una base de datos Postgres, algo que ofrece cualquier proveedor de alojamiento, no una API específica de Mythex.

3. Cada app puede tener la forma que necesita

Una app quiere una tabla bookings con una restricción única sobre los huecos horarios; otra quiere búsqueda de texto completo sobre productos. Con su propia base de datos, el esquema y las migraciones de cada app son asunto suyo. Nada tiene que encajar en un diseño de mínimo común denominador.

4. El coste sigue al uso

Como cada base de datos entra en reposo por su cuenta, una app que nadie usa cuesta casi nada, y el coste de una app muy usada aparece como una línea propia. El uso de bases de datos publicadas se factura según lo que la base de datos midió realmente: cómo funciona esa facturación.

Los compromisos

Este diseño no es gratuito:

• Arranques en frío. Una base de datos en reposo tarda un momento en despertar con la primera consulta tras un periodo de calma. Para la mayoría de las apps esto apenas se nota; para una app que debe responder al instante a cualquier hora, es algo a considerar.
• Costes con la base de datos despierta sin uso. Una base de datos permanece despierta mientras algo la consulta. Una app que sondea su base de datos cada pocos segundos la mantiene despierta todo el día y cuesta más que una que consulta bajo demanda. Si tu uso parece más alto de lo esperado, suele ser esta la razón: pide a la IA que deje de sondear y cargue los datos cuando hagan falta.
• Más piezas móviles para nosotros. Crear, seguir y limpiar miles de bases de datos da más trabajo que una sola. Ese problema es nuestro, no tuyo.

Si eres nuevo con las bases de datos

Una base de datos es el lugar donde una app guarda lo que necesita recordar. Si la idea te resulta nueva, empieza con qué es una base de datos y qué es Postgres. Cuando estés listo para construir algo que guarde datos, cómo construir una app con IA explica cómo añadirla.