Varför varje Mythex-app får sin egen databas

När en app du bygger på Mythex behöver spara data, till exempel registreringar, bokningar eller beställningar, ger Mythex projektet en egen Postgres-databas. Inte en tabell i en delad databas, inte ett schema bredvid någon annans: en separat databas, skapad vid behov, som somnar när ingen använder den. Här är varför vi byggde det så, och vad det kostar.

Vad du får

När du ber om data (“spara väntlisteadresser”, “lagra bokningar”) eller använder kommandot /database, gör Mythex följande:

• skapar en dedikerad Postgres-databas för projektet (för närvarande Postgres 17),
• lägger in anslutningsuppgifterna i din arbetsyta och i din publicerade app som miljövariabler, så att de aldrig syns i din kod, och
• låter agenten skapa tabeller och läsa och skriva data åt dig.

Samma databas används av den live-förhandsvisningen och av den publicerade appen. Den somnar efter 5 minuter utan aktivitet och vaknar vid nästa fråga. Nya databaser börjar små och kan skalas upp under belastning, med ett tak så att en lös fråga inte kan växa obegränsat. Mer finns i databasdokumentationen.

Varför inte en stor delad databas?

En delad databas med en kolumn som anger vilken app varje rad tillhör är billigare att driva och enklare att sköta. Vi valde att inte göra det, av fyra skäl.

1. Isolering du inte behöver lita på

Kod skriven av AI gör misstag. I en delad databas kunde ett saknat WHERE app_id = … i en apps fråga läsa eller skriva över en annan kunds data. Med en databas per app finns ingen annan kunds data inom räckhåll: ett fel stannar i sin egen app.

2. Det är riktig Postgres, inte ett egenutvecklat lager

Din app pratar standard-Postgres med en vanlig anslutningssträng. Varje bibliotek, ORM eller verktyg som fungerar med Postgres fungerar här. Om du exporterar ditt projekt för att köra det någon annanstans, förväntar det sig en Postgres-databas, något varje hostingleverantör erbjuder, inte ett Mythex-specifikt API.

3. Varje app kan formas efter sina behov

En app vill ha en tabell bookings med en unik begränsning på tidsluckor; en annan vill ha fulltextsökning över produkter. Med en egen databas är varje apps schema och migreringar dess egen sak. Ingenting behöver passa en design som är minsta gemensamma nämnare.

4. Kostnaden följer användningen

Eftersom varje databas somnar på egen hand kostar en app som ingen använder nästan ingenting, och en aktiv apps kostnad syns som en egen rad. Användning av publicerade databaser faktureras utifrån vad databasen faktiskt mätte: så fungerar faktureringen.

Avvägningarna

Den här designen är inte gratis:

• Kallstarter. En sovande databas tar en stund att vakna vid första frågan efter en tyst period. För de flesta appar märks det knappt; för en app som måste svara direkt när som helst är det något att tänka på.
• Kostnader när den är vaken men inaktiv. En databas förblir vaken så länge något frågar den. En app som frågar sin databas några gånger per sekund håller den vaken dygnet runt och kostar mer än en som frågar vid behov. Om din användning ser högre ut än du väntat dig är det oftast orsaken. Be AI:n sluta polla och hämta data när den behövs i stället.
• Fler rörliga delar för oss. Att skapa, följa och städa upp tusentals databaser är mer arbete än att sköta en. Det är vårt problem att bära, inte ditt.

Om du är ny till databaser

En databas är där en app håller det den behöver komma ihåg. Om idén är ny, börja med vad en databas är och vad Postgres är. När du är redo att bygga något som lagrar data visar hur du bygger en app med AI hur man lägger till den.