Hvorfor hver Mythex-app får sin egen database

Når en app, du bygger på Mythex, skal gemme data — tilmeldinger, bookinger, ordrer — får det projekt sin egen Postgres-database. Ikke en tabel i en delt database, ikke et skema ved siden af en andens: en separat database, oprettet efter behov, der går i dvale, når ingen bruger den. Her er hvorfor vi byggede det sådan, og hvad det koster.

Hvad du får

Når du beder om data ("gem venteliste-e-mails", "gem bookinger") eller bruger kommandoen /database, gør Mythex følgende:

• opretter en dedikeret Postgres-database til projektet (lige nu Postgres 17),
• indsætter forbindelsesdetaljerne i dit workspace og din publicerede app som miljøvariabler, så de aldrig optræder i din kode, og
• lader agenten oprette tabeller og læse og skrive data for dig.

Den samme database bruges af live preview og den publicerede app. Den går i dvale efter 5 minutters inaktivitet og vågner ved næste forespørgsel. Nye databaser starter små og kan skaleres op under belastning, med et loft, så en løbsk forespørgsel ikke kan vokse uden grænse. Mere i database-dokumentationen.

Hvorfor ikke én stor delt database?

En delt database med en kolonne, der siger, hvilken app hver række hører til, er billigere at køre og enklere at drifte. Vi valgte ikke det af fire grunde.

1. Isolation, du ikke skal stole på

Kode skrevet af AI laver fejl. I en delt database kunne ét manglende WHERE app_id = … i én apps forespørgsel læse eller overskrive en anden kundes data. Med en database pr. app er der ingen andre kunders data inden for rækkevidde — en fejl bliver inde i sin egen app.

2. Det er rigtig Postgres, ikke et proprietært lag

Din app taler standard Postgres med en normal forbindelsesstreng. Ethvert bibliotek, ORM eller værktøj, der virker med Postgres, virker her. Hvis du eksporterer dit projekt for at køre det andetsteds, forventer det en Postgres-database — noget enhver hostingudbyder tilbyder — ikke en Mythex-specifik API.

3. Hver app kan formes, som den har brug for

Én app vil have en bookings-tabel med en unik constraint på tidsslots; en anden vil have fuld-tekstsøgning over produkter. Med sin egen database er hver apps skema og migrationer dens egen sag. Intet behøver at passe ind i et design, der er den laveste fællesnævner.

4. Omkostningen følger brugen

Fordi hver database sover for sig selv, koster en app, som ingen bruger, næsten intet, og en travl apps omkostning er synlig som sin egen linje. Forbrug af publicerede databaser faktureres ud fra det, databasen faktisk har målt — hvordan den fakturering virker.

Afvejningerne

Dette design er ikke gratis:

• Kolde starter. En sovende database bruger et øjeblik på at vågne ved den første forespørgsel efter en stille periode. For de fleste apps er det næsten ikke til at se; for en app, der skal svare med det samme til enhver tid, er det en overvejelse.
• Omkostninger, når den er vågen uden at bruges. En database forbliver vågen, så længe noget forespørger den. En app, der poller sin database hvert par sekunder, holder den vågen døgnet rundt og koster mere end en, der forespørger efter behov. Hvis dit forbrug ser højere ud, end du forventede, er det oftest derfor — bed AI'en om at stoppe med at polle og i stedet hente data, når de skal bruges.
• Flere bevægelige dele for os. At oprette, følge og rydde op i tusindvis af databaser er mere arbejde end én. Det er vores problem at bære, ikke dit.

Hvis du er ny til databaser

En database er stedet, hvor en app gemmer det, den skal huske. Hvis idéen er ny, så start med hvad en database er og hvad Postgres er. Når du er klar til at bygge noget, der gemmer data, gennemgår hvordan man bygger en app med AI tilføjelsen.