osFoundry / Platform
Postgres на приложение
Каждое приложение получает свой Postgres с pgvector и TimescaleDB. Платите только за то, что храните.
Что это
Postgres для каждого приложения даёт каждому приложению, которое вы создаёте в osFoundry, собственную выделенную базу Postgres вместо того, чтобы заставлять все приложения делить одну схему или одно соединение. Каждая база поставляется с pgvector для хранения и поиска эмбеддингов и с TimescaleDB для данных временных рядов, поэтому одна база может содержать ваши реляционные таблицы, векторы семантического поиска и ваши метрики или потоки событий без подключения отдельных сервисов. Ключи моделей для всего, что порождает эти эмбеддинги, вы приносите сами (BYOK); а Postgres, который их хранит, выделяется для каждого приложения.
Поскольку каждое приложение изолировано в собственной базе, схема, индексы и данные одного приложения не могут столкнуться с данными другого. Эта изоляция делает приложения понятнее в рассуждении, безопаснее в доработке и чище в удалении: когда приложение исчезает, его база уходит вместе с ним. Внутри osFoundry это относится к слою Apps и Backend, поэтому создаваемое вами приложение получает настоящее серверное хранилище данных, а не игрушечное key-value, и та же база доступна серверному коду приложения, его векторному поиску и его запросам по временным рядам. osFoundry — это рабочее пространство BYOK и local-first, поэтому и здесь действует тот же принцип, что пронизывает весь продукт: ваши данные и инфраструктура, на которой они живут, остаются вашими, и никакой платы за место сверху не начисляется.
Цена следует за тем, что вы действительно используете. Вы платите только за хранимое, поэтому приложение с несколькими тысячами строк стоит соответственно, а приложение, которое так и не заполнило свою базу, не оплачивается так, будто заполнило. Это делает практичным давать каждому приложению собственный Postgres по умолчанию, даже маленьким или экспериментальным, вместо того чтобы экономить, нормируя базы данных. pgvector и TimescaleDB — часть той базы, что у вас уже есть, а не дополнения с отдельной строкой в счёте.
Ключевые возможности
- Каждому приложению выделяется собственная база Postgres, изолированная от схемы и данных любого другого приложения
- pgvector встроен для хранения и поиска эмбеддингов рядом с вашими реляционными таблицами в той же базе
- TimescaleDB встроен для временных рядов, поэтому метрики и потоки событий находятся рядом с основными таблицами приложения
- Оплата по объёму хранения: вы платите только за хранимое, поэтому небольшие и экспериментальные приложения остаются дешёвыми
- Вписывается в модель BYOK и local-first от osFoundry: ключи моделей для эмбеддингов вы предоставляете сами, а база, которая их хранит, ваша, для каждого приложения
Сценарии использования
- Создатель приложений: выпустите приложение, которому нужны реляционные таблицы, семантический поиск и дашборды, не подключая три отдельных сервиса данных
- AI-разработчик: храните эмбеддинги документов с pgvector и выполняйте поиск по сходству в том же Postgres, где лежат записи вашего приложения
- Одиночный мейкер: поднимите множество небольших приложений, каждое со своей базой, и платите только за ту горстку, где действительно накапливаются данные
Часто задаваемые вопросы
Действительно ли каждое приложение получает отдельную базу Postgres, или это один общий инстанс?
Каждое приложение получает собственную базу Postgres, изолированную от других. Её схема, индексы и данные принадлежат ей, и когда вы удаляете приложение, база уходит вместе с ним. Именно эта изоляция не даёт приложениям сталкиваться и делает их лёгкими в доработке и удалении.
Нужно ли мне самому устанавливать pgvector и TimescaleDB?
Нет. pgvector и TimescaleDB встроены в базу каждого приложения. Вы можете хранить и искать эмбеддинги и работать с временными рядами в том же Postgres, где лежат ваши реляционные таблицы, не добавляя отдельных расширений или сервисов.
Как тарифицируется Postgres для каждого приложения?
Вы платите только за хранимое. Счёт следует за вашим фактическим объёмом хранения, поэтому приложение с малым объёмом данных стоит мало, а пустые базы не оплачиваются как заполненные. Именно это делает практичным давать каждому приложению собственную базу по умолчанию.