10 сентября (чт) в Москве особое мероприятие для всех, кто интересуется передовыми решениями в области СУБД: компании «Тантор Лабс» исполняется пять лет. Мы приглашаем разработчиков СУБД, инженеров, архитекторов, администраторов, представителей заказчиков и партнеров, чтобы обсудить, куда движется российская инфраструктура данных и какие технологии уже сейчас меняют привычный подход к работе с Postgres-инфраструктурой.
Вадим Яценко, генеральный директор «Тантор Лабс»5 лет «Тантор Лабс». Российским СУБД пора играть по-крупному
Алексей Барган, руководитель отдела разработки Платформы Tantor AI-first подход в управлении и администрировании СУБД. Как меняется профессия DBA?
Семен Курепин, пресейл-инженер Платформа Tantor 7.0: Интеграция предиктивной аналитики в контур эксплуатации СУБД
Алексей Копытов, архитектор, tech lead Tantor Polar: путь к «колоночному» HTAP через конвейерную обработку heap
Екатерина Мартьянова, директор по продукту Tantor XData; Михаил Сёмкин, team lead СУБД Tantor Polar Машина баз данных Tantor XData Gen3: постгресовый дрифт в сторону enterprise
Максим Милютин, руководитель группы исследований и разработки Нативная (без ETL) аналитика на оригинальных данных. PX-движок для Tantor Polar
Александр Симонов, технический руководитель направления развития 1С Postgres для 1С: от «работает» к «быстро» — за два года
Сергей Соловьев, разработчик СУБД Tantor Postgres Новая эпоха TDE
Андрей Погудин, инженер Защита данных в Tantor Postgres
10 августа я провёл вебинар, посвящённый новым возможностям Digital Q.DataBase 18.2 - СУБД + AI в Digital Q.DataBase
В программе:
🔹 Развитие полиглотной платформы единая платформа для PostgreSQL, Microsoft SQL Server и Oracle; новые возможности совместимости; 🔹 Новые возможности RuDB новые пакеты; развитие функциональности; 🔹 ИИ и векторный поиск поддержка векторных операций; 🔹 KV-хранилище DGrid развитие встроенного KV-хранилища; архитектура решения;
► Бесплатная полнофункциональная версия дистрибутива (до 8 ядер) с возможностью использования в том числе в коммерческих целях.
► С 1 сентября 2026 года компания «Диасофт» переходит на новую лицензионную политику СУБД Digital Q.DataBase (до 4-х ядер).
Как redb хранит сложные объекты: не бесхемная свалка, а RTTI
Про redb (RedBase) есть два зеркальных заблуждения. Первое: раз объект пишется «как документ», внутри лежит сериализованный JSON или блоб. Второе, противоположное: раз всё падает в общую таблицу значений — значит это плоский мешок пар «ключ-значение» без схемы.
Оба мимо. То, что внутри — это RTTI, полноценная система типов, живущая в самой базе. И устроена она заметно сложнее, чем и блоб, и «атрибут-значение». Разбор архитектуры я подробно давал в отдельной статье на Хабре: «redb: реляционное хранилище объектов» — ниже сжатая суть.
Слой типов: база знает настоящий тип каждого поля
redb хранит не только данные, но и их описание типов — три связанных уровня:
types — реальные дескрипторы типов (db_type и соответствие .NET-типу);
_schemes — сами типы (классы), с поддержкой наследования через self-reference;
structures — типизированные поля схемы: имя (name), тип (_id_type, FK на types), признак коллекции (collection_type) и вложенность (_id_parent).
Значения в values всегда привязаны к конкретной структуре (id_structure, FK на structures). Поэтому строка values — это не безымянная пара «атрибут-значение»: это значение известного, именованного, типизированного, возможно вложенного поля известного класса. База в рантайме знает, что перед ней — decimal Salary в схеме Employee, а не абстрактный «атрибут №42». Это и есть RTTI.
Хранение коллекций: построчно, реляционно
Вложенные массивы, словари и глубокие иерархии redb раскладывает в _values построчно, а не строкой:
Никаких JSON-блобов на диске. Каждый элемент коллекции — отдельная строка с типизированными колонками (_value_long, valuestring, valuedatetime, valueguid, …), внешними ключами и обычными индексами.
Связь и порядок — реляционные. Вложенность собирается self-reference колонкой arrayparent_id (FK на values.id, ON DELETE CASCADE). Порядок массива и ключи словаря — в arrayindex (text: '0','1','2' для массивов, строковый ключ — для словарей).
Один элемент — одна строка.List<OrderItem> внутри класса не превращается ни в JSON-поле, ни в десяток физических таблиц, которые вы заводите руками.
Что это даёт на практике
Честный LINQ на уровне СУБД. Данные лежат в типизированных колонках, а метаданные структур позволяют движку собрать нативный SQL: Where / OrderBy / GroupBy / оконные функции идут по реальным индексам базы, а не перебором JSON в памяти бэкенда.
Загрузка за один запрос без каскада JOIN-ов. Чтобы поднять объект со всей глубиной вложенности (пусть там 20–30 списков), не нужен каскад JOIN, как у EF с .Include(). Плоская структура забирается из _values одним запросом и собирается в объект в памяти.
Точечный Change Tracking (Pro). При сохранении Pro-версия строит деревья ValueTreeNode (память против БД), сравнивает их (ValueTreeBuilder / ValueTreeDiff) и шлёт UPDATE только по изменившимся узлам — граф целиком не перезаписывается.
Итог: redb совмещает удобство работы с объектами «как с документами» и фундамент реляционной СУБД — типизацию, индексы, FK и запросы, которые исполняет база, а не бэкенд. Ключ к этому — не блоб и не плоский мешок атрибутов, а persisted-RTTI: types → schemes → structures → values.
Информационные технологии. Проблемы и решения – IT'DAYS
Сегодня всё чаще говорят: импортозамещение заканчивается там, где начинается переписывание миллионов строк бизнес-логики.
Именно поэтому всё больший интерес вызывают полиглотные СУБД, которые позволяют заменить СУБД, а не приложение, сохранив привычные языки программирования и существующую бизнес-логику.
Digital Q.DataBase — именно такая СУБД. Она воспроизводит функциональные возможности Microsoft SQL Server и Oracle Database, позволяя существенно сократить объём доработок существующих информационных систем при миграции.
Отличный повод вспомнить моё выступление на международной конференции «Информационные технологии. Проблемы и решения – IT'DAYS» в Уфе.
► Бесплатная полнофункциональная версия дистрибутива (до 8 ядер) с возможностью использования в том числе в коммерческих целях.
Приглашаем на вебинар «СУБД + AI: векторные операции, LLM и полиглотная архитектура в Digital Q.DataBase»
10 августа в 13:00 (мск) компания «Диасофт» проведет практический вебинар о новых возможностях Digital Q.DataBase «СУБД + AI: векторные операции, LLM и полиглотная архитектура в Digital Q.DataBase».
Вебинар «СУБД + AI: векторные операции, LLM и полиглотная архитектура в Digital Q.DataBase»
Ключевые темы:
Полиглотная архитектура Digital Q.DataBase. Как в единой среде работать с базами PostgreSQL, Microsoft SQL Server и Oracle
Симбиоз СУБД и AI. Поддержка векторных операций и интеграция с большими языковыми моделями (LLM) под капотом СУБД
Высокая скорость работы с данными. Архитектура и новые возможности встроенного KV-хранилища DGrid для сверхбыстрого доступа к информации
Развитие RuDB. Обзор новой функциональности и обновленных пакетов платформы
Как реализовать семантический поиск для RAG-архитектуры в PostgreSQL без усложнения инфраструктуры?
Ситуация: вы разрабатываете чат-бота для техподдержки на базе RAG-архитектуры. Используете PostgreSQL как хранилище знаний и делаете поиск по текстовым полям, но качество ответов нестабильное: система плохо справляется с синонимами, профессиональным сленгом и переформулировками запросов. Обязательно ли внедрять отдельную векторную базу данных, или можно реализовать семантический поиск прямо в PostgreSQL? Возможна ли простая проверка продуктовой гипотезы без усложнения архитектуры?
Да, семантический поиск в RAG-сценариях можно реализовать прямо в PostgreSQL без выделенной векторной базы данных (ClickHouse, Opensearch, Qdrant, Milvus и т. д).
Для этого используется PostgreSQL + расширение pgvector, которое добавляет поддержку хранения эмбеддингов (векторов) и поиск по расстоянию до ближайших соседей (KNN) прямо внутри SQL-движка. Разберем, как это работает на практике.
В RAG-пайплайне текст документов и запрос пользователя преобразуются в векторные представления. PostgreSQL хранит эти векторы в таблице и позволяет выполнять поиск по смысловой близости, а не по точному совпадению слов.
Для этой задачи будем использовать pgvector — это расширение к PostgreSQL, которое добавляет тип данных vector и операторы поиска по расстоянию до ближайших соседей (KNN).
Поддерживаются три основные метрики сравнения векторов:
L2 (евклидово расстояние) — классическое расстояние между двумя точками в многомерном пространстве. Хорошо работает, если векторы не нормализованы и распределение значений относительно равномерное.
Cosine similarity (косинусное сходство). В отличие от предыдущей метрики измеряет не абсолютное расстояние, а угол между двумя векторами. Подходит для текстовых эмбеддингов, где важна направленность, а не масштаб. Требует нормализации векторов.
Inner product (внутреннее произведение) — скалярное произведение двух векторов. Может использоваться как прокси для оценки «сходства» при обучении моделей и в задачах ранжирования.
Допустим, мы получаем на наш запрос именно такой вектор от модели OpenAI. Для хранения создаем таблицу с типом VECTOR:
CREATE TABLE items (
id SERIAL PRIMARY KEY,
title TEXT,
embedding VECTOR(1536)
);
Добавим данные для нескольких векторов разных объектов:
Теперь сравним их попарно и отсортируем по расстоянию:
SELECT
a.title AS title_a,
b.title AS title_b,
a.embedding <-> b.embedding AS distance
FROM items a
JOIN items b ON a.id < b.id
ORDER BY distance;
Оператор <-> здесь вычисляет расстояние между двумя векторами. Таким образом, мы можем оценивать степень семантической близости любых объектов, представленных векторами. Какая именно метрика используется, зависит от операторного класса, заданного при создании индекса.
В подобных RAG-сценариях нет необходимости сразу вводить отдельный класс инфраструктуры типа векторная БД. Семантический поиск можно реализовать эволюционно поверх существующего PostgreSQL.
А если вы не хотите самостоятельно заниматься настройкой индексов, тюнингом памяти и производительности, а также обновлением версии PostgreSQL, то воспользуйтесь DBaaS от Selectel. Мы предоставим вам кластер PostgreSQL с преднастроенными расширениями, готовый к эксплуатации под нагрузкой. Это позволит сосредоточиться на RAG-логике и качестве поиска, а не на инфраструктурной оптимизации.
Как разрешить пользователю реплики удаленно подключаться к Master-серверу PostgreSQL?
Вы настраиваете отказоустойчивый кластер баз данных. При попытке синхронизировать реплику с мастер-сервером соединение обрывается с ошибками сетевого доступа. В каком конфигурационном файле и как именно нужно прописать доступы, чтобы Master принял входящее подключение?
По умолчанию PostgreSQL придерживается строгой политики безопасности и блокирует любые удаленные попытки подключения, если они не разрешены в подсистеме авторизации.
Чтобы решить эту проблему, необходимо отредактировать конфигурационный файл клиентской аутентификации pg_hba.conf на стороне Master-сервера и явно разрешить репликацию для IP-адреса вашей реплики.
Для доступа к реплицируемым данным у пользователя replicator должна быть привилегия replication:
ALTER ROLE replicator WITH REPLICATION;
Предварительно ознакомьтесь с порядком применения правил в pg_hba.conf в официальной документации.
Чтобы PostgreSQL применил изменения в конфигурации авторизации, выполните reload службы в терминале:
systemctl reload postgresql
В качестве альтернативы можно отправить сигнал процессу postmaster с помощью pg_ctl reload, вызовом SQL-функции pg_reload_conf() или используя kill -HUP.
После применения изменений Master-сервер начнет принимать входящие пакеты от указанного IP-адреса, и процесс репликации сможет успешно инициализироваться.
На первый взгляд, настройка репликации в PostgreSQL кажется простой задачей: достаточно открыть доступ в pg_hba.conf и подключить standby-сервер.
Но в production-инфраструктуре за этой «простой настройкой» скрывается целый стек инженерных задач: необходимо следить за консистентностью WAL-журнала, контролировать лаг между репликами, обеспечивать безопасную сетевую доступность между узлами, настраивать резервное копирование, регулярно тестировать сценарии аварийного переключения и быть готовым вручную восстанавливать кластер в случае деградации одного из серверов.
Поэтому в ряде сценариев современные команды переходят от self-managed PostgreSQL к PaaS-решениям вроде Managed Databases, где отказоустойчивость, репликация и обслуживание кластера уже реализованы на уровне платформы.
Это позволяет сократить операционные расходы на сопровождение инфраструктуры и снизить риск простоев критичных сервисов.
Приглашаем на пятилетие «Тантор Лабс». 10 сентября - Tantor JAM 2026
Первый юбилей Tantor — пять лет с момента основания компании. За это время мы прошли путь от стартапа до технологического лидера, одного из ведущих российских разработчиков в области управления и хранения данных, создали собственную экосистему продуктов и собрали вокруг себя сообщество, которое сегодня во многом определяет развитие российского рынка СУБД.
Программу скоро представим. Среди главных премьер:
Новое поколение Платформы Tantor, основанное на AI-first подходе. Представим ИИ-администратора БД с целым роем специализированных ИИ-агентов, которые возьмут на себя рутинные операции по работе с СУБД.
Результаты испытаний МБД Tantor XData Gen3 на различных профилях нагрузки. Покажем, как enterprise-технологии, ранее доступные только в зарубежных решениях, — независимое масштабирование Compute и Storage, RDMA, распределенная файловая система и полноценный HTAP — становятся доступны в российском ПАКе.
Подробнее расскажем о Tantor Polar — новой распределенной СУБД, открывающей следующий этап развития российских PostgreSQL-технологий с полным сохранением совместимости с экосистемой Postgres.
Вас ждут выступления руководителей разработки, общение с инженерами, архитекторами, заказчиками и партнерами, а также праздничная программа в честь пятилетия компании.
1 июля мы провели вебинар, посвящённый новым возможностям Digital Q.DataBase 18.2.
В рамках вебинара я, Андрей Жуйков, амбассадор компании «Диасофт», рассказал о ключевых возможностях Digital Q.DataBase 18.2 — масштабном обновлении, направленном на развитие совместимости с корпоративными СУБД и упрощение миграции существующих систем.
Изменения коснулись Microsoft SQL Server-направления: расширена поддержка T-SQL, Service Broker, CLR-сборок, механизма CDC, а также появилась служба отчётов Digital Q.DataBase, совместимая с SQL Server Reporting Services (SSRS).
Отдельное внимание уделено Oracle-направлению: расширена поддержка Oracle-совместимых пакетов, курсоров и Bind-переменных, улучшена работа JDBC-драйвера, доработаны средства миграции Oracle-объектов, а также появилась новая технология автоматизированного перевода Oracle Forms в современные приложения.
На вебинаре рассмотрим ключевые изменения релиза, покажем их практическое применение и расскажем, как новые возможности помогают ускорить миграцию корпоративных систем и снизить затраты на переход на российскую СУБД.
В программе:
🔹 Обзор Digital Q.DataBase 18.2 Ключевые изменения релиза. Развитие совместимости с Microsoft SQL Server и Oracle. Новые возможности для миграции корпоративных систем.
🔹 Новая версия CDC Обновлённый механизм Change Data Capture. Новый веб-интерфейс управления. Сценарии применения и преимущества.
🔹 Новые возможности миграции и совместимости Расширение совместимости с Microsoft SQL Server. Новые Oracle-пакеты и развитие Oracle-диалекта. Поддержка CLR-сборок. Развитие Service Broker.
🔹 Служба отчётов Digital Q.DataBase Аналог SQL Server Reporting Services (SSRS). Поддержка RDL-отчётов. Формирование отчётов в HTML и PDF.
🔹 Новая технология перевода Oracle Forms Автоматизированный перевод Oracle Forms в современные приложения. Архитектура решения. Демонстрация технологии.
► Бесплатная полнофункциональная версия дистрибутива (до 8 ядер) с возможностью использования в том числе в коммерческих целях.
В этом докладе Илья Виссарионов рассказывает о практическом опыте компании «Диасофт» по импортозамещению крупной автоматизированной банковской системы, которая десятилетиями работала на Microsoft SQL Server.
Главной особенностью проекта стало то, что значительная часть бизнес-логики была реализована в виде хранимых процедур. Полное переписывание миллионов строк SQL-кода оказалось бы слишком дорогим и длительным, поэтому был выбран другой путь — развитие Digital Q.DataBase с максимальной совместимостью с Microsoft SQL Server и сохранением существующих приложений.
В докладе подробно рассматриваются реальные технические проблемы, с которыми столкнулась команда при переносе банковской системы на PostgreSQL-совместимую платформу: различия в типах данных, работе процедур, оптимизаторе запросов, производительности, временных таблицах, пользовательских типах данных и других механизмах СУБД.
Отдельное внимание уделено нагрузочному тестированию. Автор показывает, как поэтапная оптимизация Digital Q.DataBase позволила добиться производительности, сравнимой с Microsoft SQL Server, а по ряду операций — превзойти её, при этом сохранив существующую бизнес-логику без масштабного переписывания.
В этом видео вы узнаете:
🔹 почему импортозамещение крупных банковских систем требует особого подхода; 🔹 с какими проблемами столкнулась команда при переносе АБС с Microsoft SQL Server; 🔹 почему стандартного PostgreSQL оказалось недостаточно; 🔹 какие механизмы совместимости были реализованы в Digital Q.DataBase; 🔹 как удалось сохранить существующий T-SQL-код без его переписывания; 🔹 какие доработки были выполнены для повышения производительности; 🔹 как проводилось нагрузочное тестирование на реальных банковских сценариях; 🔹 каких результатов удалось добиться по сравнению с Microsoft SQL Server.
Если вас интересуют вопросы импортозамещения СУБД, миграции корпоративных систем или построения PostgreSQL-совместимых платформ корпоративного уровня — этот доклад будет полезен разработчикам, архитекторам, администраторам баз данных и техническим руководителям.
Digital Q.DataBase — российская СУБД корпоративного уровня, разработанная компанией «Диасофт» для замещения Microsoft SQL Server, Oracle и других зарубежных решений. Платформа позволяет сохранить существующие инвестиции в прикладной код и значительно сократить трудозатраты при миграции информационных систем.
Как мы воспроизводим функциональность Oracle и создаем аналоги DBMS-пакетов.
В предыдущем посте я рассказывал о технологии «Полиглот» в Digital Q.DataBase — возможности исполнять T-SQL "на лету" наряду с родным PL/pgSQL, что позволяет мигрировать приложения с Microsoft SQL Server.
Но полиглотность Digital Q.DataBase этим не ограничивается.
Сегодня хочу поделиться выступлением моего коллеги Ильи Лебедева, посвящённым Oracle-направлению. В докладе он подробно рассказывает о поддержке PL/SQL и о том, как Digital Q.DataBase помогает переносить системы с Oracle, сохраняя серверную бизнес-логику и клиентские приложения без дорогостоящей переработки.
В этом выступлении обсуждаются:
🔹 Как Digital Q.DataBase реализует полноценную поддержку Oracle-диалекта, включая пакеты, DBMS-пакеты и PL/SQL-код. 🔹 Почему SQL- и PL/SQL-код может выполняться без изменений. 🔹 Как работает мастер переноса баз данных и какие скорости миграции можно получить на практике. 🔹 Каким образом обеспечивается бесшовное подключение существующих приложений через OCI и JDBC. 🔹 Почему переход с Oracle на Digital Q.DataBase может занять месяцы вместо лет. 🔹 Как накопленный опыт миграций позволяет ускорять последующие проекты и снижать объем доработок.
В докладе также показаны реальные сценарии переноса корпоративных систем, демонстрация работы клиентских приложений после замены СУБД и подход компании к развитию совместимости с Oracle на основе запросов заказчиков.
Digital Q.DataBase — российская СУБД корпоративного уровня, разработанная компанией «Диасофт» для замещения Microsoft SQL Server, Oracle и других зарубежных решений. Платформа позволяет сохранить существующие инвестиции в прикладной код и значительно сократить трудозатраты при миграции информационных систем.
В этом докладе я (Жуйков Андрей, амбассадор компании «Диасофт») рассказываю о подходе Digital Q.DataBase к импортозамещению зарубежных СУБД и миграции корпоративных систем без переписывания прикладного кода.
В видео рассмотрены:
🔹 архитектура и возможности Digital Q.DataBase; 🔹 технология Polyglot и поддержка нескольких SQL-диалектов в одной СУБД; 🔹 совместимость с Microsoft SQL Server и Oracle; 🔹 исполнение T-SQL и PL/SQL без изменения бизнес-логики приложений; 🔹 поддержка протокола TDS и работа со стандартными драйверами Microsoft; 🔹 миграция 1С с Microsoft SQL Server на Digital Q.DataBase; 🔹 демонстрация работы через DBeaver, SQL Server Management Studio и Python; 🔹 поддержка Service Broker, Reporting Services и CLR-сборок; 🔹 примеры реальных проектов и опыт внедрения у заказчиков.
Digital Q.DataBase — российская СУБД корпоративного уровня, разработанная компанией «Диасофт» для замещения Microsoft SQL Server, Oracle и других зарубежных решений.
Платформа позволяет сохранить существующие инвестиции в прикладной код и значительно сократить трудозатраты при миграции информационных систем.
Определяет представление планировщика об эффективном размере дискового кеша, доступном для одного запроса. Это представление влияет на оценку стоимости использования индекса; чем выше это значение, тем больше вероятность, что будет применяться сканирование по индексу, чем ниже, тем более вероятно, что будет выбрано последовательное сканирование.
Вот прямо с первых строк мозги выносит: при чём тут оценка (ОЦЕНКА!) размера дискового кэша и выбор между индексным или полным сканированием? Не знаю, кому как, но лично мне совсем непонятно. Следующее, если effective_cache_size показывает оценку размера ДИСКОВОГО кеша (для меня одного словосочетание “дисковый кэш” означает “кэш файловой системы”?), то откуда взялась рекомендация в значение 3/4 размера оперативной памяти, если 1/4 - это shared_buffers? Рекомендатели, ау! 1/4 + 3/4 = 1, арифметика, начальная школа. А где СУБД должна выполнять манипуляции с данными? В свопе? Всё остальное описание совершенно не добавляет ясности по использованию данного параметра, увы нам, постгресовым администраторам баз данных.
Кратко. Главное. Данный параметр показывает ОБЩИЙ размер кэша: постгресовый shared_buffersплюс (плюс выделен жирным шрифтом в оригинальной статье!) кэш файловой системы. С этим уточнением рекомендация в 3/4 размера оперативной памяти выглядит приемлемой. Следующее. Обсуждаемый параметр применяется для вычисления вероятности того, что однажды прочитанные данные будут находиться в кэше при повторном обращении в рамках ОДНОГО запроса. Т.е. для предпочтения соединения таблиц вложенным циклом (Nested loop join) при выборе методов соединения. Если высока вероятность того, что данных при повторном запросе в кэше не окажется, то будет выбрано либо полное сканирование таблиц(ы), либо сканирование по битовой маске, либо соединение хешем (hash join), либо соединение слиянием (merge join). Далее. Этот параметр - верхняя оценка, завышенное значение не приводит к серьёзным проблемам (по крайней мере в статье об этом говорится). Ограничение. effective_cache_size должен быть больше shared_buffers, ибо меньшее значение является бессмысленным (по статье).
30 июня эксперты «Тантор Лабс» представят разбор Tantor XData Gen3 — третьего поколения машины баз данных для высоконагруженных корпоративных систем, реализующей ряд технологий, ранее доступных в таких западных продуктах как Oracle Exadata, SAP HANA и IBM Netezza.
В программе:
эволюция архитектуры Tantor XData и ключевые изменения в Gen3: независимое масштабирование подсистем вычислений и хранения, полноценная обработка смешанной нагрузки (HTAP) на едином наборе данных;
новые возможности платформы и сценарии их применения;
устройство и особенности распределенной СУБД Tantor Polar;
организация вычислительных ресурсов и ресурсов хранения;
инструменты управления и мониторинга.
Отдельный блок будет посвящён практической работе с машиной баз данных. Пройдем интерактив с реальным ситуациями, демонстрирующими преимущества новой машины баз данных перед классическими СУБД.
Эксперты мероприятия:
Вадим Яценко, генеральный директор «Тантор Лабс»
Сергей Серегин, руководитель технического пресейл «Тантор Лабс».
Мой опыт с Supabase: 8 неочевидных костылей, о которых молчат в красивых туториалах.
Все вокруг хвалят Supabase за скорость. И да, я тоже повелся. Как бэкендера меня поначалу знатно корежило от того, что фронт ходит тупо прямиком в базу. Но ради быстрой доставки фичей я зажмурился.
Спойлер: пилится-то всё реально быстро. Только потом ты ловишь тихие баги, пропадающие логи и жесткий вендор-лок. Я собрал на Supabase уже несколько проектов и успел поседеть.
Короче, вот за что вы будете страдать на бесплатном тарифе (да и не только на нем).
Логи. Их просто нет Точнее, они живут ровно 24 часа. Упало что-то в пятницу вечеро - в понедельник с утра ты дебажишь святым духом. Встроенный поиск это вообще кровь из глаз. Без какого-нибудь Datadog или Logflare там тупо не выжить.
Edge-функции и проклятые холодные старты Это отдельный котел. Писать надо на Deno, так что половина привычных npm-пакетов идет лесом. Лимиты на вызовы жесткие, долгую таску не запустить. Но самое бесячее — холодные старты. Пока поднимется пул коннектов к базе, проходит до трех секунд. В моем сервисе post-cooler.ruedge-функция отдает HTML для линк-страничек. Я смотрю в метрики и плачу: кликов куча, а дожидаются загрузки единицы. Конверсия просто умирает на этапе бесконечного лоадера.
Палево с доменами в OAuth Юзер логинится через Google, а в окне авторизации торчит <project-id>.supabase.co. Я когда делал photo math, целый час дебажил эту хрень. Думал, что сам где-то накосячил — на локалке-то всё выглядело нормально! Оказалось, не баг, а фича. Хочешь свой домен? Плати.
Хаос со схемами БД Экспорт схем из дашборда выпилили еще в 2025 году. Сейчас помогаю проекту the-signal переехать на селф-хост. До этого код там писали vibe-кодеры, которые вообще не парились про миграции. Вытащить дамп схемы из облака было той еще болью. Без жесткой дисциплины база очень быстро превращается в неуправляемую помойку.
Тормоза локальной разработки Я постоянно прыгаю между проектами. И каждый гребаный раз supabase start лезет тянуть свежие Docker-образы. Поднимает 10+ контейнеров, а ты сидишь и тупишь в терминал. Весь кайф от "быстрой" разработки улетучивается.
Тихие RLS-ошибки RLS (Row Level Security) ошибается молча. Накосячил в политиках? БД тебе не скажет. UPDATE просто вернет 0 affected rows, а SELECT подтянет половину данных.
Транзакции и боль SQL-функций Через REST API нельзя сделать нормальную транзакцию на несколько таблиц. Нужно атомарно создать юзера, профиль и настройки? Обломись. У меня пока ничего не отвалилось, но я с ужасом жду, когда в базе начнут копиться "осиротевшие" записи. Чтобы это обойти, приходится писать логику на PL/pgSQL прямо в базе. Редактор там примитивный, автокомплита толком нет и дебажить то еще удовольствие.
Вендор-лок Клиентский SDK намертво завязан на специфичный синтаксис PostgREST и их собственные токены. Если однажды решишь переехать на нормальный самописный бэк: придется рефакторить вообще весь клиентский код.
Короче. Для MVP или пет-проекта, чтобы просто проверить гипотезу на коленке - это топ. Да, часть этих костылей можно вылечить, если закинуть денег и перейти на платную версию. Но возникает резонный вопрос: за те же 25 баксов в месяц можно спокойно поднять Supabase на нормальной VPS-ке и вообще забыть про лимиты.
Кто еще сидит на Supabase или Firebase? С чем боретесь? И есть тут те, кто уже психанул и переехал на свой бэк?
Сегодня к вечеру я совсем обленился и решил доверить нейронке storege создать к коннектору в библиотеку redb.route используя redb Изучала дольше чем писала. 😊 Накидала в одну сессию за один проход с тестами. __ Аудитория: разработчики уже подключают DSL-маршруты к redb.Route, которые хотят, чтобы LLM был полноценным пользователем конвейера - с памятью, бюджетом, разрешениями и аудиторским журналом, а не HTTP—вызовом без сохранения состояния, который ничего не оставляет после себя. единый линейный маршрут.Услуги.AddRedbLlmStorage() — переключает цикл работы агента с "забывает все при перезапуске" на постоянную систему по умолчанию. Все пять поверхностей (расшифровки, утверждения, бюджеты, идемпотентность, аудит) перемещаются в redb. Ни одна строка кода маршрута не меняется — ваш существующий .To("llm://claude") начинает сохраняться сам по себе.
Тут в ленту прилетела новость, которая касается всех постгресменов, кто пользуется pgbackrest-ом для создания резервных копий. Либо собирается им пользоваться. А именно, создатель и разработчик проекта закончил работу над ним: https://github.com/pgbackrest/pgbackrest#notice-of-obsolescence. Грусть, печаль, тоска, тлен и безысходность. :( И статью править, и исходный материал в ЖЖ.
Вебинар о том, как обеспечить стабильность баз данных при росте проекта и нагрузок
Самостоятельное администрирование баз данных может превратиться в рутину: постоянные обновления, бэкапы, мониторинг и работа с нагрузкой. С ростом проекта стандартных настроек уже не хватает, а риск просадок и простоев из-за ошибок в конфигурации становится выше.
Это третий вебинар из большого трека про эволюцию приложения в облаке. На этот раз разберем, как передать обслуживание PostgreSQL управляемому сервису в облаке и настроить архитектуру Master/Replica для стабильной работы при высоких нагрузках.
О чем будем говорить:
сравним управляемую и self-hosted СУБД PostgreSQL: выясним, когда пора задуматься о переезде;
разберем ключевые метрики БД: на что обращать внимание в мониторинге, чтобы не доводить до инцидента;
обсудим, как архитектура Master/Replica повышает отказоустойчивость приложения.
После теории будет насыщенное демо, на котором покажем, как добавить в сервис поддержку нескольких реплик и разгрузить базу на чтении. Затем проведем нагрузочное тестирование и сравним показатели до и после оптимизации. Еще покажем, как организовать резервное копирование, разделить трафик на чтение и запись и повысить отказоустойчивость приложения.
Вебинар будет полезен бэкенд-разработчикам, DevOps- и SRE-инженерам, архитекторам и тимлидам, которые отвечают за стабильность базы данных, производительность сервисов и развитие приложения под растущей нагрузкой.
