Perché ogni app Mythex ha il proprio database

Quando un'app che costruisci su Mythex ha bisogno di salvare dati, come iscrizioni, prenotazioni o ordini, Mythex dà a quel progetto il proprio database Postgres. Non una tabella in un database condiviso, né uno schema accanto a quello di qualcun altro: un database separato, creato su richiesta, che va in pausa quando nessuno lo usa. Ecco perché l'abbiamo costruito così, e cosa costa.

Cosa ottieni

Quando chiedi dei dati («salva le email della lista d'attesa», «memorizza le prenotazioni») oppure usi il comando /database, Mythex:

• crea un database Postgres dedicato per il progetto (attualmente Postgres 17),
• inserisce i dettagli di connessione nel tuo spazio di lavoro e nell'app pubblicata come variabili d'ambiente, così non compaiono mai nel codice, e
• permette all'agente di creare tabelle e leggere e scrivere dati per te.

Lo stesso database è usato dall'anteprima dal vivo e dall'app pubblicata. Va in pausa dopo 5 minuti di inattività e si risveglia alla query successiva. I nuovi database partono piccoli e possono scalare sotto carico, con un tetto così che una query fuori controllo non possa crescere senza limiti. Maggiori dettagli nella documentazione sui database.

Perché non un unico grande database condiviso?

Un database condiviso con una colonna che indica a quale app appartiene ogni riga costa meno da gestire ed è più semplice da far funzionare. Abbiamo scelto di non farlo per quattro motivi.

1. Isolamento di cui non devi fidarti

Il codice scritto dall'IA commette errori. In un database condiviso, un WHERE app_id = … dimenticato nella query di un'app potrebbe leggere o sovrascrivere i dati di un altro cliente. Con un database per app, non ci sono dati di altri clienti a portata di mano: un bug resta all'interno della sua app.

2. È un Postgres vero, non un livello proprietario

La tua app parla con un Postgres standard tramite una normale stringa di connessione. Qualsiasi libreria, ORM o strumento che funziona con Postgres funziona qui. Se esporti il tuo progetto per eseguirlo altrove, si aspetta un database Postgres, cioè qualcosa che ogni provider di hosting offre, non un'API specifica di Mythex.

3. Ogni app può essere modellata come le serve

Un'app vuole una tabella bookings con un vincolo di unicità sugli slot orari; un'altra vuole una ricerca full-text sui prodotti. Con un database proprio, schema e migrazioni di ogni app sono affari suoi. Nulla deve adattarsi a un design di compromesso minimo comune.

4. Il costo segue l'uso

Poiché ogni database va in pausa per conto suo, un'app che nessuno usa costa quasi nulla, e il costo di un'app molto usata appare come una voce separata. L'uso dei database pubblicati viene fatturato in base a ciò che il database ha effettivamente misurato: come funziona questa fatturazione.

I compromessi

Questo design non è gratuito:

• Avvii a freddo. Un database in pausa impiega un momento a risvegliarsi alla prima query dopo un periodo di calma. Per la maggior parte delle app è appena percepibile; per un'app che deve rispondere istantaneamente a qualsiasi ora, è una considerazione da fare.
• Costi da sveglio ma inattivo. Un database resta sveglio finché qualcosa lo interroga. Un'app che interroga il suo database ogni pochi secondi lo tiene sveglio tutto il giorno e costa più di una che interroga solo quando serve. Se il tuo consumo sembra più alto del previsto, di solito è questo il motivo: chiedi all'IA di smettere di interrogare in continuazione e di caricare i dati quando servono.
• Più parti mobili per noi. Creare, tracciare e ripulire migliaia di database è più lavoro che gestirne uno. Quel peso è nostro, non tuo.

Se non conosci i database

Un database è il posto in cui un'app conserva ciò che deve ricordare. Se l'idea ti è nuova, inizia da cos'è un database e cos'è Postgres. Quando sarai pronto a costruire qualcosa che memorizza dati, come costruire un'app con l'IA spiega come aggiungerlo.