Hvorfor hver Mythex-app får sin egen database

Når en app du bygger på Mythex trenger å lagre data, som påmeldinger, bestillinger eller ordrer, får prosjektet sin egen Postgres-database. Ikke en tabell i en felles database, ikke et skjema ved siden av andres: en egen database, opprettet på forespørsel, som sover når ingen bruker den. Her er hvorfor vi bygde det slik, og hva det koster.

Hva du får

Når du ber om data («lagre påmeldinger til ventelisten», «lagre bestillinger») eller bruker kommandoen /database, gjør Mythex følgende:

• oppretter en dedikert Postgres-database for prosjektet (foreløpig Postgres 17),
• legger forbindelsesdetaljene inn i arbeidsområdet ditt og i den publiserte appen som miljøvariabler, slik at de aldri står i koden din, og
• lar agenten opprette tabeller og lese og skrive data for deg.

Den samme databasen brukes av den levende forhåndsvisningen og den publiserte appen. Den går i dvale etter 5 minutter uten aktivitet og våkner ved neste spørring. Nye databaser starter små og kan skaleres opp under belastning, med et tak slik at en løpsk spørring ikke kan vokse uten grenser. Mer finner du i databasedokumentasjonen.

Hvorfor ikke én stor felles database?

En felles database med en kolonne som sier hvilken app hver rad tilhører, er billigere å drifte og enklere å betjene. Vi valgte likevel å ikke gjøre det, av fire grunner.

1. Isolasjon du ikke må stole på

AI-skrevet kode gjør feil. I en felles database kunne ett manglende WHERE app_id = … i én apps spørring lese eller overskrive en annen kundes data. Med én database per app finnes ingen andre kunders data innen rekkevidde, og en feil holder seg innenfor sin egen app.

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

Appen din snakker vanlig Postgres med en normal tilkoblingsstreng. Ethvert bibliotek, ORM eller verktøy som fungerer med Postgres, fungerer her. Hvis du eksporterer prosjektet for å kjøre det et annet sted, forventer det en Postgres-database, noe hver hostingleverandør tilbyr, og ikke et Mythex-spesifikt API.

3. Hver app kan formes slik den trenger

Én app vil ha en tabell bookings med en unik begrensning på tidsluker. En annen vil ha fulltekstsøk over produkter. Med sin egen database er skjema og migreringer for hver app dens egen sak. Ingenting må passe inn i en design som er minste felles multiplum.

4. Kostnaden følger bruken

Fordi hver database går i dvale for seg selv, koster en app som ingen bruker, nesten ingenting, og en travel apps kostnad vises som sin egen linje. Bruk av publiserte databaser faktureres ut fra det databasen faktisk målte. Se hvordan faktureringen fungerer.

Avveiningene

Dette designet er ikke gratis:

• Kaldstarter. En sovende database bruker et øyeblikk på å våkne ved første spørring etter en rolig periode. For de fleste apper merkes det knapt. For en app som må svare øyeblikkelig til enhver tid, er det noe å ta hensyn til.
• Kostnader når den er våken uten å være i bruk. En database holder seg våken så lenge noe spør den. En app som spør databasen hvert par sekunder, holder den våken døgnet rundt og koster mer enn en som spør etter behov. Hvis forbruket ditt ser høyere ut enn du forventet, er det vanligvis grunnen. Be AI-en slutte å polle, og laste data når de trengs.
• Flere bevegelige deler for oss. Å opprette, følge med på og rydde opp i tusenvis av databaser er mer arbeid enn én. Det er vårt problem å bære, ikke ditt.

Hvis du er ny til databaser

En database er stedet en app holder på det den må huske. Hvis ideen er ny, start med hva en database er og hva Postgres er. Når du er klar til å bygge noe som lagrer data, viser hvordan du bygger en app med AI hvordan du legger det til.