Чому кожен застосунок Mythex отримує власну базу даних

Коли застосунку, який ви будуєте на Mythex, потрібно зберігати дані (реєстрації, бронювання, замовлення), Mythex дає цьому проєкту власну базу Postgres. Не таблицю в спільній базі і не схему поруч з чиєюсь іншою, а окрему базу, створювану за потреби, яка засинає, коли нею ніхто не користується. Ось чому ми це зробили так і що це коштує.

Що ви отримуєте

Коли ви просите дані («зберігай email-адреси зі списку очікування», «зберігай бронювання») або використовуєте команду /database, Mythex:

• створює для проєкту окрему базу Postgres (наразі Postgres 17),
• передає параметри підключення у ваш робочий простір і опублікований застосунок як змінні середовища, тож вони ніколи не з'являються у вашому коді, і
• дозволяє агенту створювати таблиці та читати й записувати дані за вас.

Ту саму базу використовують живий попередній перегляд і опублікований застосунок. Вона засинає після 5 хвилин простою і прокидається з наступним запитом. Нові бази стартують маленькими й можуть масштабуватися під навантаженням, з верхньою межею, щоб некоректний запит не міг рости без обмежень. Більше в документації з баз даних.

Чому не одна велика спільна база?

Спільна база, де стовпець показує, якому застосунку належить кожен рядок, дешевша в роботі й простіша в обслуговуванні. Ми обрали інше з чотирьох причин.

1. Ізоляція, яку не треба довіряти

Код, написаний ШІ, помиляється. У спільній базі одна пропущена умова WHERE app_id = … у запиті одного застосунку могла б прочитати або перезаписати дані іншого клієнта. З базою на кожен застосунок до чужих даних немає жодного доступу: помилка лишається всередині свого застосунку.

2. Це справжній Postgres, а не власний шар

Ваш застосунок говорить зі стандартним Postgres зі звичайним рядком підключення. Будь-яка бібліотека, ORM чи інструмент, що працює з Postgres, працює і тут. Якщо ви експортуєте проєкт, щоб запустити його деінде, він очікує базу Postgres, яку пропонує кожен хостинг-провайдер, а не API, специфічний для Mythex.

3. Кожен застосунок може мати потрібну йому форму

Одному застосунку потрібна таблиця bookings з унікальним обмеженням на часові слоти, іншому потрібен повнотекстовий пошук по товарах. Маючи власну базу, схема і міграції кожного застосунку належать лише йому. Нічому не доводиться вміщуватися в спільний дизайн, який влаштовує всіх найменше.

4. Вартість слідує за використанням

Оскільки кожна база засинає окремо, застосунок, яким ніхто не користується, майже нічого не коштує, а вартість зайнятого застосунку видно як окремий рядок. Використання опублікованої бази тарифікується за тим, що база фактично виміряла; як це працює.

Компроміси

Цей дизайн не безкоштовний:

• Холодні старти. Сплячій базі потрібен момент, щоб прокинутися з першим запитом після тиші. Для більшості застосунків це майже непомітно; для застосунку, який має відповідати миттєво в будь-яку годину, це варто врахувати.
• Витрати, коли база не спить. База залишається активною, поки що-небудь до неї звертається. Застосунок, який опитує свою базу кожні кілька секунд, тримає її активною цілодобово і коштує більше, ніж той, що запитує за потреби. Якщо ваше використання виглядає вищим, ніж ви очікували, зазвичай причина саме в цьому: попросіть ШІ припинити опитування і завантажувати дані тоді, коли вони потрібні.
• Більше рухомих частин для нас. Створення, відстеження та прибирання тисяч баз складніше, ніж однієї. Це наша проблема, а не ваша.

Якщо ви тільки знайомитеся з базами даних

База даних це місце, де застосунок зберігає те, що має пам'ятати. Якщо ця ідея нова, почніть з що таке база даних і що таке Postgres. Коли будете готові побудувати щось, що зберігає дані, як побудувати застосунок за допомогою ШІ покаже, як її додати.