De ce fiecare aplicație Mythex primește propria bază de date

Când o aplicație construită pe Mythex are nevoie să salveze date — înscrieri, rezervări, comenzi — Mythex îi oferă proiectului propria bază Postgres. Nu un tabel într-o bază comună, nu o schemă lângă a altcuiva: o bază separată, creată la cerere, care doarme când nimeni nu o folosește. Iată de ce am construit-o așa și ce costă.

Ce primești

Când ceri date („salvează adresele din lista de așteptare”, „stochează rezervări”) sau folosești comanda /database, Mythex:

• creează o bază Postgres dedicată proiectului (în prezent Postgres 17),
• injectează detaliile de conectare în spațiul tău de lucru și în aplicația publicată, ca variabile de mediu, astfel încât să nu apară niciodată în codul tău, și
• îi permite agentului să creeze tabele și să citească și să scrie date pentru tine.

Aceeași bază este folosită de preview-ul live și de aplicația publicată. Ea doarme după 5 minute de inactivitate și se trezește la următoarea interogare. Bazele noi pornesc mici și pot scala sub încărcare, cu un plafon, ca o interogare defectă să nu poată crește nelimitat. Mai multe în documentația despre baze de date.

De ce nu o singură bază mare, comună?

O bază comună, cu o coloană care spune ce aplicație deține fiecare rând, este mai ieftină de rulat și mai simplu de administrat. Am ales să nu o facem, din patru motive.

1. Izolare în care nu trebuie să ai încredere

Codul scris de AI greșește uneori. Într-o bază comună, lipsa unui singur WHERE app_id = … din interogarea unei aplicații ar citi sau ar suprascrie datele altui client. Cu o bază per aplicație, datele niciunui alt client nu sunt la îndemână — o eroare rămâne în propria aplicație.

2. Este un Postgres real, nu un strat proprietar

Aplicația ta vorbește cu Postgres standard, printr-un șir de conectare obișnuit. Orice bibliotecă, ORM sau unealtă care funcționează cu Postgres funcționează și aici. Dacă îți exporți proiectul ca să-l rulezi în altă parte, el are nevoie de o bază Postgres — ceva ce oferă orice furnizor de hosting — nu de un API specific Mythex.

3. Fiecare aplicație poate fi modelată după nevoile ei

O aplicație vrea un tabel bookings cu o constrângere de unicitate pe intervalele orare; alta vrea căutare full-text peste produse. Cu propria bază, schema și migrările fiecărei aplicații sunt treaba ei. Nimic nu trebuie să se potrivească unui design de tip cel mai mic numitor comun.

4. Costul urmează utilizarea

Pentru că fiecare bază doarme separat, o aplicație pe care nu o folosește nimeni costă aproape nimic, iar costul unei aplicații aglomerate apare ca un rând propriu. Utilizarea bazelor publicate este facturată pe baza a ceea ce a măsurat efectiv baza de date — cum funcționează facturarea.

Compromisurile

Designul acesta nu este gratuit:

• Porniri la rece. O bază adormită are nevoie de un moment ca să se trezească la prima interogare după o perioadă liniștită. Pentru majoritatea aplicațiilor abia se observă; pentru o aplicație care trebuie să răspundă instant oricând, este o considerație.
• Costuri când este trează, dar inactivă. O bază rămâne trează cât timp o interoghează ceva. O aplicație care întreabă baza de date la fiecare câteva secunde o ține trează non-stop și costă mai mult decât una care interoghează la cerere. Dacă utilizarea ta pare mai mare decât te aștepți, de obicei acesta este motivul — cere AI-ului să nu mai facă polling și să încarce datele doar când sunt necesare.
• Mai multe piese în mișcare pentru noi. Crearea, urmărirea și curățarea a mii de baze este mai multă muncă decât a uneia. Asta este problema noastră de dus, nu a ta.

Dacă ești nou în domeniul bazelor de date

O bază de date este locul unde o aplicație își ține ce are nevoie să-și amintească. Dacă ideea este nouă, începe cu ce este o bază de date și ce este Postgres. Când ești gata să construiești ceva care stochează date, cum să construiești o aplicație cu AI explică pas cu pas cum o adaugi.