Waarom elke Mythex-app zijn eigen database krijgt

Wanneer een app die je op Mythex bouwt data moet opslaan, zoals aanmeldingen, boekingen of bestellingen, krijgt dat project zijn eigen Postgres-database. Geen tabel in een gedeelde database, geen schema naast dat van iemand anders: een aparte database, op aanvraag aangemaakt, die slaapt wanneer niemand hem gebruikt. Hier is waarom we het zo hebben gebouwd, en wat het kost.

Wat je krijgt

Wanneer je om data vraagt („bewaar wachtlijst-e-mails”, „sla boekingen op”) of het commando /database gebruikt, doet Mythex het volgende:

• maakt een eigen Postgres-database voor het project aan (momenteel Postgres 17),
• zet de verbindingsgegevens als omgevingsvariabelen in je werkruimte en in je gepubliceerde app, zodat ze nooit in je code verschijnen, en
• laat de agent tabellen aanmaken en data voor je lezen en schrijven.

Dezelfde database wordt gebruikt door de live preview en de gepubliceerde app. Hij slaapt na 5 minuten inactiviteit en wordt wakker bij de volgende query. Nieuwe databases beginnen klein en kunnen opschalen onder belasting, met een plafond zodat een ontsporende query niet onbeperkt kan groeien. Meer in de databasedocumentatie.

Waarom niet één grote gedeelde database?

Een gedeelde database met een kolom die aangeeft tot welke app elke rij behoort, is goedkoper te draaien en eenvoudiger te beheren. We hebben daar vier redenen niet voor gekozen.

1. Isolatie waarop je niet hoeft te vertrouwen

AI-geschreven code maakt fouten. In een gedeelde database zou één ontbrekende WHERE app_id = … in de query van één app de data van een andere klant kunnen lezen of overschrijven. Met een database per app is er geen data van een andere klant binnen bereik; een bug blijft binnen zijn eigen app.

2. Het is echt Postgres, geen eigen laag

Je app praat met standaard Postgres via een gewone verbindingsstring. Elke bibliotheek, ORM of tool die met Postgres werkt, werkt hier ook. Als je je project exporteert om het ergens anders te draaien, verwacht het een Postgres-database, iets wat elke hostingprovider aanbiedt, geen Mythex-specifieke API.

3. Elke app kan worden gevormd zoals hij nodig heeft

Eén app wil een tabel bookings met een unieke constraint op tijdslots; een andere wil volledige-tekstzoekopdrachten over producten. Met een eigen database zijn het schema en de migraties van elke app zijn eigen zaak. Niets hoeft te passen in een ontwerp dat voor iedereen het kleinste gemene deler is.

4. De kosten volgen het gebruik

Omdat elke database apart slaapt, kost een app die niemand gebruikt bijna niets, en is de kost van een druk gebruikte app zichtbaar als een eigen regel. Gepubliceerd databasegebruik wordt gefactureerd op basis van wat de database daadwerkelijk heeft gemeten: hoe die facturatie werkt.

De afwegingen

Dit ontwerp is niet gratis:

• Koude starts. Een slapende database heeft een moment nodig om wakker te worden bij de eerste query na een rustige periode. Voor de meeste apps valt dat nauwelijks op; voor een app die op elk uur direct moet antwoorden, is het een aandachtspunt.
• Kosten van wakker zijn. Een database blijft wakker zolang iets hem bevraagt. Een app die zijn database elke paar seconden pollt, houdt hem de hele dag wakker en kost meer dan een app die op verzoek bevraagt. Als je gebruik hoger lijkt dan je verwachtte, is dit meestal de reden: vraag de AI om met pollen te stoppen en data pas te laden wanneer die nodig is.
• Meer bewegende delen voor ons. Duizenden databases aanmaken, bijhouden en opruimen is meer werk dan één. Dat is ons probleem om te dragen, niet het jouwe.

Als je nieuw bent met databases

Een database is de plek waar een app bewaart wat hij moet onthouden. Als het idee nieuw is, begin met wat een database is en wat Postgres is. Wanneer je klaar bent om iets te bouwen dat data opslaat, loopt hoe je een app met AI bouwt door het toevoegen ervan.