Miért kap minden Mythex-app saját adatbázist

Amikor a Mythexen épített app adatot akar menteni — regisztrációkat, foglalásokat, rendeléseket —, a Mythex az adott projektnek saját Postgres-adatbázist ad. Nem egy táblát egy közös adatbázisban, és nem egy sémát valaki másé mellett: külön adatbázist, igény szerint létrehozva, amely elalszik, ha senki nem használja. Elmagyarázzuk, miért így építettük, és mibe kerül.

Mit kapsz

Ha adatot kérsz („mentsd el a várólistás e-maileket”, „tárold a foglalásokat”), vagy a /database parancsot használod, a Mythex:

• létrehoz egy dedikált Postgres-adatbázist a projektnek (jelenleg Postgres 17),
• a kapcsolati adatokat környezeti változókként beilleszti a munkaterületedbe és a publikált appba, így azok soha nem jelennek meg a kódodban, és
• lehetővé teszi, hogy az ügynök táblákat hozzon létre, és helyetted olvasson és írjon adatot.

Ugyanazt az adatbázist használja az élő előnézet és a publikált app. Öt tétlen perc után elalszik, és a következő lekérdezésre ébred. Az új adatbázisok kicsik, és terhelés alatt felskálázódhatnak, egy plafonnal, hogy egy elszabadult lekérdezés ne nőhessen határtalanul. Részletek az adatbázis-dokumentációban.

Miért nem egyetlen nagy közös adatbázis?

Egy közös adatbázis, amelyben egy oszlop mondja meg, melyik apphoz tartozik minden sor, olcsóbb az üzemeltetéshez, és egyszerűbb is. Négy okból döntöttünk úgy, hogy nem így csináljuk.

1. Elszigeteltség, amelyben nem kell bíznod

Az AI által írt kód hibázik. Egy közös adatbázisban egy hiányzó WHERE app_id = … egy appnak a lekérdezésében másik ügyfél adatait olvashatná vagy írhatná felül. Appónként egy adatbázissal nincs más ügyfél adata elérhető közelségben — egy hiba a saját appján belül marad.

2. Igazi Postgres, nem zárt réteg

Az appod szokványos Postgres-kapcsolati sztringgel beszél az adatbázissal. Minden könyvtár, ORM vagy eszköz, amely Postgresszel működik, itt is működik. Ha exportálod a projektedet, hogy máshol futtasd, Postgres-adatbázist vár — ilyet minden hosting-szolgáltató kínál —, nem egy Mythex-specifikus API-t.

3. Minden app úgy alakítható, ahogy szüksége van

Az egyik app egy bookings táblát akar egyedi megkötéssel az időrésekre; egy másik teljes szöveges keresést a termékeken. Saját adatbázissal minden app sémája és migrációi saját ügye. Semminek nem kell beleférnie egy legkisebb közös nevező tervezésbe.

4. A költség követi a használatot

Mivel minden adatbázis külön alszik el, egy app, amelyet senki nem használ, szinte semmibe nem kerül, az elfoglalt app költsége pedig saját tételként látszik. A publikált adatbázis-használat a ténylegesen mért mennyiség alapján kerül számlázásra — hogyan működik a számlázás.

A kompromisszumok

Ez a tervezés nem ingyen van:

• Hideg indulás. Egy alvó adatbázis az első lekérdezésnél egy pillanatra felébred egy csendes időszak után. A legtöbb appnál ez alig észrevehető; egy olyan appnál, amelynek bármikor azonnal kell válaszolnia, ez szempont.
• Ébren maradás költsége. Egy adatbázis ébren marad, amíg bármi lekérdezi. Egy app, amely néhány másodpercenként lekérdezi az adatbázisát, egész nap ébren tartja azt, és többe kerül, mint egy, amely igény szerint kérdez. Ha a használatod magasabbnak tűnik, mint vártad, ez általában az oka — kérd meg az AI-t, hogy hagyja abba a lekérdezgetést, és csak szükség esetén töltse be az adatot.
• Több mozgó alkatrész nekünk. Ezer adatbázis létrehozása, nyomon követése és takarítása több munka, mint egyé. Ezt a mi dolgunk cipelni, nem a tiéd.

Ha új vagy az adatbázisokban

Az adatbázis az a hely, ahol az app megőrzi azt, amire emlékeznie kell. Ha a fogalom új, kezd a mi az adatbázis és a mi az a Postgres útmutatóval. Amikor olyasmit akarsz építeni, amely adatot tárol, a hogyan építs appot AI-val végigvezet az adat hozzáadásán.