Почему у каждого приложения Mythex своя база данных

Когда приложение, которое вы строите в Mythex, должно сохранять данные — регистрации, брони, заказы, — Mythex выделяет этому проекту собственную базу Postgres. Не таблицу в общей базе и не схему рядом с чужой: отдельную базу, которая создаётся по запросу и засыпает, когда ей никто не пользуется. Вот почему мы построили именно так и чего это стоит.

Что вы получаете

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

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

Та же база используется живым превью и опубликованным приложением. Она засыпает после 5 минут простоя и просыпается по следующему запросу. Новые базы стартуют маленькими и могут увеличиваться под нагрузкой, с потолком, чтобы runaway-запрос не рос без предела. Подробнее — в документации по базам данных.

Почему не одна большая общая база?

Общая база, в которой столбец указывает, какому приложению принадлежит каждая строка, дешевле в эксплуатации и проще в обслуживании. Мы решили так не делать по четырём причинам.

1. Изоляция, которой не нужно доверять

Код, написанный AI, ошибается. В общей базе одно пропущенное WHERE app_id = … в запросе одного приложения прочитало бы или перезаписало бы данные другого клиента. Когда у каждого приложения своя база, чужие данные недоступны вовсе — ошибка остаётся внутри своего приложения.

2. Это настоящий Postgres, а не проприетарный слой

Ваше приложение общается со стандартным Postgres через обычную строку подключения. Любая библиотека, ORM или инструмент, которые работают с Postgres, работают и здесь. Если вы экспортируете проект, чтобы запустить его где-то ещё, ему нужна база Postgres — есть у любого хостинга, — а не API, специфичный для Mythex.

3. Каждое приложение может быть устроено так, как ему нужно

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

4. Стоимость следует за использованием

Поскольку каждая база засыпает сама по себе, приложение, которым никто не пользуется, стоит почти ничего, а стоимость загруженного приложения видна отдельной строкой. Использование опубликованной базы оплачивается по тому, что база реально измерила, — как устроена эта оплата.

Компромиссы

У такой схемы есть цена:

• Холодный старт. Спящая база требует времени на пробуждение при первом запросе после затишья. Для большинства приложений это почти незаметно; для приложения, которое обязано отвечать мгновенно в любое время, это важно.
• Стоимость бодрствования. База не спит, пока что-то к ней обращается. Приложение, которое опрашивает базу каждые несколько секунд, держит её бодрствующей круглосуточно и стоит дороже, чем приложение, которое обращается к базе по требованию. Если ваше использование выше, чем вы ожидали, обычно причина в этом — попросите AI перестать опрашивать базу и загружать данные по мере необходимости.
• Больше подвижных частей для нас. Создавать, отслеживать и очищать тысячи баз сложнее, чем одну. Эта нагрузка наша, а не ваша.

Если вы впервые работаете с базами данных

База данных — это место, где приложение хранит то, что ему нужно помнить. Если идея новая, начните с что такое база данных и что такое Postgres. Когда будете готовы построить что-то, что хранит данные, как создать приложение с помощью AI проведёт через её подключение.