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 otro: una base de datos independiente, creada bajo demanda, que se duerme cuando nadie la usa. Aquí explicamos por qué la construimos así y cuánto cuesta.

Qué obtienes

Cuando pides datos («guarda los correos de la lista de espera», «almacena 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, de modo que nunca aparecen en tu código, y
• deja que el agente cree tablas y lea y escriba datos por ti.

La misma base de datos la usan la vista previa en vivo y la app publicada. Se duerme tras 5 minutos inactivos 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. Decidimos no hacerlo por cuatro razones.

1. Un aislamiento en el que no tienes que confiar

El código escrito con IA comete errores. En una base de datos compartida, un WHERE app_id = … que falte 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 error se queda dentro de su propia app.

2. Es un Postgres de verdad, 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 hosting, y 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 en 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 se duerme por separado, una app que nadie usa cuesta casi nada, y el coste de una app muy activa aparece como una línea propia. El uso de bases de datos publicadas se factura a partir de lo que la base de datos midió realmente: cómo funciona esa facturación.

Los compromisos

Este diseño no es gratis:

• Arranques en frío. Una base de datos dormida tarda un momento en despertar con la primera consulta tras un periodo de calma. En la mayoría de las apps apenas se nota; en una app que tiene que responder al instante a cualquier hora, es algo a tener en cuenta.
• Costes de estar despierta sin actividad. Una base de datos permanece despierta mientras algo la consulta. Una app que consulta 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 por esto: pide a la IA que deje de consultar en bucle y que cargue los datos cuando hagan falta.
• Más piezas móviles para nosotros. Crear, seguir y limpiar miles de bases de datos es más trabajo que hacerlo con una. Ese problema lo cargamos nosotros, no tú.

Si eres nuevo con las bases de datos

Una base de datos es donde una app guarda lo que necesita recordar. Si el concepto es nuevo, empieza con qué es una base de datos y qué es Postgres. Cuando estés listo para construir algo que guarde datos, cómo crear una app con IA explica paso a paso cómo añadirla.