Dlaczego każda aplikacja Mythex dostaje własną bazę danych

Gdy aplikacja, którą budujesz w Mythex, musi zapisywać dane — rejestracje, rezerwacje, zamówienia — ten projekt dostaje własną bazę Postgres. Nie tabelę we wspólnej bazie, nie schemat obok cudzego: osobną bazę, tworzoną na żądanie, która zasypia, gdy nikt jej nie używa. Oto dlaczego zbudowaliśmy to właśnie tak i co to kosztuje.

Co dostajesz

Gdy prosisz o dane („zapisuj e-maile z listy oczekujących”, „przechowuj rezerwacje”) albo używasz polecenia /database, Mythex:

• tworzy dedykowaną bazę Postgres dla projektu (obecnie Postgres 17),
• wstrzykuje dane połączenia do Twojej przestrzeni roboczej i opublikowanej aplikacji jako zmienne środowiskowe, więc nigdy nie pojawiają się w kodzie, oraz
• pozwala agentowi tworzyć tabele i odczytywać oraz zapisywać dane za Ciebie.

Ta sama baza jest używana przez podgląd na żywo i opublikowaną aplikację. Zasypia po 5 minutach bezczynności i budzi się przy następnym zapytaniu. Nowe bazy zaczynają mały i mogą się powiększać pod obciążeniem, z sufitem, żeby zapytanie, które wymknie się spod kontroli, nie rosło bez końca. Więcej w dokumentacji baz danych.

Dlaczego nie jedna duża wspólna baza?

Wspólna baza, w której kolumna mówi, do której aplikacji należy każdy wiersz, jest tańsza w utrzymaniu i prostsza w obsłudze. Nie zdecydowaliśmy się na nią z czterech powodów.

1. Izolacja, której nie musisz nikomu ufać

Kod pisany przez AI popełnia błędy. We wspólnej bazie jedno brakujące WHERE app_id = … w zapytaniu jednej aplikacji mogłoby odczytać albo nadpisać dane innego klienta. Przy bazie na aplikację nie ma w zasięgu danych żadnego innego klienta — błąd zostaje w swojej aplikacji.

2. To prawdziwy Postgres, a nie zastrzeżona warstwa

Twoja aplikacja rozmawia ze standardowym Postgresem przez zwykły ciąg połączenia. Każda biblioteka, ORM lub narzędzie, które działa z Postgresem, działa tutaj. Jeśli wyeksportujesz projekt, żeby uruchomić go gdzie indziej, będzie oczekiwał bazy Postgres — czegoś, co oferuje każdy dostawca hostingu — a nie API specyficznego dla Mythex.

3. Każda aplikacja może mieć kształt, którego potrzebuje

Jedna aplikacja chce tabelę bookings z unikalnym ograniczeniem na sloty czasowe; inna chce pełnotekstowego wyszukiwania po produktach. Mając własną bazę, schemat i migracje każdej aplikacji są jej własną sprawą. Nic nie musi pasować do wspólnego najmniejszego wspólnego mianownika.

4. Koszt idzie za użyciem

Skoro każda baza zasypia osobno, aplikacja, z której nikt nie korzysta, kosztuje prawie nic, a koszt aktywnej aplikacji jest widoczny jako jej własna pozycja. Użycie opublikowanych baz jest rozliczane na podstawie tego, co baza faktycznie zmierzyła — jak działa to rozliczanie.

Kompromisy

Ten projekt nie jest darmowy:

• Zimne starty. Śpiąca baza potrzebuje chwili, żeby się obudzić przy pierwszym zapytaniu po cichym okresie. Dla większości aplikacji to ledwo zauważalne; dla aplikacji, która musi odpowiadać natychmiast o każdej porze, to coś do rozważenia.
• Koszty, gdy jest nie śpi. Baza pozostaje obudzona, dopóki cokolwiek ją odpytuje. Aplikacja, która odpytuje bazę co kilka sekund, trzyma ją na chodzie całą dobę i kosztuje więcej niż ta, która pyta na żądanie. Jeśli Twoje zużycie wygląda wyżej, niż się spodziewasz, zwykle to jest powód — poproś AI, żeby przestało odpytywać i ładowało dane wtedy, gdy są potrzebne.
• Więcej ruchomych części po naszej stronie. Tworzenie, śledzenie i sprzątanie tysięcy baz to więcej pracy niż jednej. To nasz problem do udźwignięcia, a nie Twój.

Jeśli dopiero zaczynasz z bazami danych

Baza to miejsce, w którym aplikacja trzyma to, co musi zapamiętać. Jeśli ten pomysł jest dla Ciebie nowy, zacznij od czym jest baza danych i czym jest Postgres. Gdy będziesz gotowy zbudować coś, co przechowuje dane, jak zbudować aplikację z AI pokazuje, jak ją dodać.