Why Every Mythex App Gets Its Own Database
Each Mythex app that needs data gets its own Postgres database that sleeps when idle. Why we chose one database per app over a shared one, and the trade-offs.
Mythex Team · · 3 min read
When an app you build on Mythex needs to save data — sign-ups, bookings, orders — Mythex gives that project its own Postgres database. Not a table in a shared database, not a schema next to someone else's: a separate database, created on demand, that sleeps when nobody is using it. Here's why we built it that way, and what it costs.
What you get
When you ask for data ("save waitlist emails", "store bookings") or use the /database command, Mythex:
- creates a dedicated Postgres database for the project (currently Postgres 17),
- injects the connection details into your workspace and your published app as environment variables, so they never appear in your code, and
- lets the agent create tables and read and write data for you.
The same database is used by the live preview and the published app. It sleeps after 5 idle minutes and wakes on the next query. New databases start small and can scale up under load, with a ceiling so a runaway query can't grow without bound. More in the database docs.
Why not one big shared database?
A shared database with a column saying which app each row belongs to is cheaper to run and simpler to operate. We chose not to do it for four reasons.
1. Isolation you don't have to trust
AI-written code makes mistakes. In a shared database, one missing WHERE app_id = … in one app's query would read or overwrite another customer's data. With a database per app, there's no other customer's data in reach — a bug stays inside its own app.
2. It's a real Postgres, not a proprietary layer
Your app talks to standard Postgres with a normal connection string. Any library, ORM or tool that works with Postgres works here. If you export your project to run it elsewhere, it expects a Postgres database — something every hosting provider offers — not a Mythex-specific API.
3. Each app can be shaped the way it needs
One app wants a bookings table with a unique constraint on time slots; another wants full-text search over products. With its own database, each app's schema and migrations are its own business. Nothing has to fit a lowest-common-denominator design.
4. Cost follows use
Because each database sleeps on its own, an app nobody is using costs almost nothing, and a busy app's cost is visible as its own line. Published database usage is billed from what the database actually measured — how that billing works.
The trade-offs
This design isn't free:
- Cold starts. A sleeping database takes a moment to wake on the first query after a quiet spell. For most apps this is barely noticeable; for an app that must answer instantly at any hour, it's a consideration.
- Idle-but-awake costs. A database stays awake while anything queries it. An app that polls its database every few seconds keeps it awake around the clock and costs more than one that queries on demand. If your usage looks higher than you expect, this is usually why — ask the AI to stop polling and load data when it's needed instead.
- More moving parts for us. Creating, tracking and cleaning up thousands of databases is more work than one. That's our problem to carry, not yours.
If you're new to databases
A database is where an app keeps what it needs to remember. If the idea is new, start with what a database is and what Postgres is. When you're ready to build something that stores data, how to build an app with AI walks through adding it.