Базы данных *

небольшой пост, куча разрозненных статей про разные части(в основном технических), вообще что это такое и зачем. здесь просто - что это такое и как это используется в реале. всё опен- сорс, открыто и бесплатно, тут нет продаж и маркетинга. и не найдете фраз по типу "покупайте наших слонов".

Главная выгода от использования единой экосистемы redb (RedBase) вместо разрозненных библиотек — это радикальное сокращение стоимости и времени разработки (Time-to-Market).

Автор спроектировал все четыре компонента (Core, Route, Tsak, Identity) так, чтобы они идеально знали друг друга «из коробки». Для бизнеса и разработчиков это дает пять ключевых преимуществ:

1. Архитектурная гармония (Один стек — один стиль)

В классическом .NET-приложении вам приходится собирать «зоопарк» из чужеродных технологий: Entity Framework для БД, MassTransit для очередей, Keycloak для авторизации и Hangfire для задач. Каждый инструмент имеет своего автора, свои правила.

• Выгода: В redb вся экосистема написана в едином стиле на чистом C#. Вы один раз понимаете логику работы фреймворка, и вам больше не нужно переучиваться при переходе от работы с базой данных к настройке безопасности или очередей сообщений.

2. Избавление от «инфраструктурного ада»

Чтобы начать enterprise-разработку по классическому пути, вам нужно развернуть десятки сервисов, настроить SQL-миграции, прописать Docker-контейнеры.

• Выгода: С RedBase вы забываете про SQL-миграции. База данных сама адаптируется под ваши C#-классы при старте. А благодаря встроенному серверу авторизации redb.Identity и движку redb.Route, вам не нужно разворачивать тяжелые внешние сервисы вроде Keycloak или Apache Camel — всё работает внутри единого .NET-процесса.

3. Колоссальная экономия времени на старте ( я бы выделил это отдельно)

Вместо того чтобы тратить первые недели (или даже месяцы) проекта на настройку авторизации, логирования, интеграционных шин и доступов к СУБД, разработчик использует готовые шаблоны dotnet new redb.

• Выгода: Вы получаете рабочее приложение с готовой базой, встроенным веб-сервером, авторизацией и роутингом за 5 минут. Бизнес-логику можно писать сразу, не отвлекаясь на техническую рутину.

4. Экстремальная производительность (In-Memory мосты)

Когда ваши микросервисы общаются между собой, они обычно гоняют трафик по сети через HTTP или gRPC, что тратит ресурсы процессора и создает задержки (latency).

• Выгода: Компоненты экосистемы redb общаются друг с другом в памяти одного процесса через специальный direct-vm - мост (redb.Route.Core). Например, проверка прав пользователя в Identity или передача сообщения в шину Route происходит мгновенно, без сетевых задержек.

5. Снижение стоимости владения и поддержки (Zero-Key Pro)

Многие современные фреймворки завлекают бесплатной базовой версией, но требуют огромных денег за коммерческие «Pro»-функции (кэширование, массовые операции, аудит).

6. DevOps-рантайм готовый к эксплуатации (redb.Tsak): Этот компонент полностью закрывает вопросы девелопмента и поддержки в проде. Он предоставляет готовый кластерный контейнер для Kubernetes с нативными пробами, сбором метрик (OpenTelemetry/Prometheus) и встроенным веб-дашбордом. Самая крутая фича для админов — Hot-Reload модулей без перезапуска процесса, что позволяет обновлять бизнес-логику на лету, не теряя сообщения «в полете» и давая возможность дежурному вручную «переигрывать» упавшие транзакции прямо из панели управления. Как микросервисом так и монолитом, или можно собрать свою версию.

• Выгода: Все Enterprise-пакеты экосистемы RedBase с приставкой .Pro являются абсолютно бесплатными. Вы получаете оптимизированные bulk-операции, продвинутый трекинг изменений и кэш без покупки лицензионных ключей.

Итог для бизнеса: Меньше серверов для поддержки, меньше кода для написания, меньше багов на стыке разных библиотек, и как результат — кратное удешевление разработки продукта.

Если было полезно, ⭐ на GitHub поможет другим это найти.

Другие мои статьи — redb.ru/articles, ещё — на Хабре.

Подборка вебинаров на сентябрь

В сентябре покажем, как за пять дней построить Data Lakehouse, защитить данные при работе с LLM, выстроить безопасную ИИ-инфраструктуру и обеспечить отказоустойчивость PostgreSQL для продакшен-нагрузок. Выбирайте интересную тему и регистрируйтесь. 

Как построить управляемый Data Lakehouse за неделю на Evolution Data Platform
Покажем, как за несколько дней с нуля построить архитектуру Data Lakehouse на Evolution Data Platform — от загрузки сырых данных до курированных витрин. Разберем принципы работы с Apache Iceberg, централизованное управление метаданными, контроль качества данных, единый SQL-слой и оркестрацию пайплайнов. Все увидите на демо.
🧑‍💻 Для кого: архитекторы данных, дата-инженеры, руководители аналитики и data-направлений, ИТ-директора, специалисты по управлению данными.
📅 Когда: 8 сентября, 11:00 мск.
📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

Как защитить чувствительные данные при работе с LLM с помощью Guardrails
Разберем, как работают Guardrails LLM и Guardrails Filter: чем они отличаются, какие данные помогают обнаруживать и как адаптировать правила проверки под задачи компании. Отдельно рассмотрим, как защитный слой Guardrails работает в контуре Evolution Foundation Models, а также какую роль в проверке запросов играют модели-классификаторы HiveTrace. На демо покажем работу open source версии Guardrails Filter.
🧑‍💻 Для кого: специалисты по защите данных и ИБ, команды разработки ИИ-приложений и тем, кто внедряет LLM в бизнес-процессы.
📅 Когда: 15 сентября, 11:00 мск.
📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

ИИ в облаке: кто отвечает за безопасность
Безопасность ИИ в облаке — это общая ответственность провайдера и бизнеса. Разберем, где проходят границы этой ответственности и как выстроить безопасную ИИ-инфраструктуру без лишних рисков. Обсудим подход Zero Trust: расскажем, как контролировать доступ к данным, моделям и сервисам в Cloud.ru Evolution и какую роль в этом играет Evolution Managed Identities (IAM).
🧑‍💻 Для кого: руководители и специалисты по ИБ (CISO), архитекторы и инженеры, проектирующие ИИ-инфраструктуру, специалисты, работающие с чувствительными данными, руководители, отвечающие за внедрение ИИ в компании.
📅 Когда: 17 сентября, 11:00 мск.
📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

PostgreSQL для продакшен-нагрузок: Multi-AZ, реплики и переключение ролей
От доступности PostgreSQL зависит стабильная работа backend-сервисов и пользовательских сценариев. Разберем, как обеспечить высокую доступность PostgreSQL в облаке. Покажем, как в Evolution Managed PostgreSQL устроена архитектура Multi-AZ, какую роль играют реплики базы данных и как работают ручное и автоматическое переключение при плановых работах и сбоях.
🧑‍💻 Для кого: DevOps-инженеры, SRE-инженеры, инфраструктурные инженеры и все технические специалисты, работающие с PostgreSQL.
📅 Когда: 29 сентября, 11:00 мск.
📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

Юлий Гольдберг (GlowByte): Lakehouse — уже не экспериментальное направление

В интервью на РБК руководитель направления GlowByte Юлий Гольдберг рассказал о том, как меняется рынок СУБД в России, почему Lakehouse перестал быть экспериментом и какие барьеры остаются у отечественных вендоров.

Ключевое из интервью:

Рынок СУБД: от срочного импортозамещения к зрелости. Заказчики всё реже ищут просто «российскую альтернативу» — они выбирают платформу под архитектуру данных, аналитику и ИИ-сценарии. При этом многие крупные компании не торопятся отказываться от Oracle и MS SQL: лицензии постоянные, системы «вылизаны», а миграция — дорогой и долгий проект.

Главный тренд — переход к Lakehouse. Вместо монолитных СУБД (Oracle, Teradata) — разделение хранения (S3+Parquet/Iceberg) и систем обработки (Spark, Trino, Impala). Подход доказал состоятельность: GlowByte совместно с Data Sapience за три года реализовали более 15 проектов, крупнейшие — на несколько петабайт данных.

Архитектура усложняется, но становится гибче. СУБД в новой парадигме — это набор взаимодополняющих компонентов. Можно собрать ровно то, что нужно, и не платить за лишнее. Но нагрузка на архитекторов и DevOps‑инженеров растет в разы.

Главный барьер — размер рынка. Российский рынок СУБД небольшой по сравнению с мировым, экспорт технологий затруднен. Инвестиции в продукты несопоставимы с зарубежными. Почти все российские СУБД, кроме ClickHouse и Tarantool, базируются на open source, а риски смены лицензий (как в случае с Greenplum) сохраняются.

ИИ меняет требования к СУБД. LLM и AI-агенты работают с неструктурированными данными — текстами, картинками. Традиционные СУБД заточены под структурированную информацию, а Lakehouse с S3-хранилищем и набором движков обработки закрывает этот пробел.

Критерии выбора СУБД на 2027 год: стоимость владения, горизонтальное масштабирование для крупных компаний, managed‑сервисы для небольших игроков.

Российский рынок СУБД на сегодня — это рынок различных клонов Postgres. Как ни смотри, хоть в штуках, хоть в деньгах. И вряд ли что-то здесь изменится в ближайшем будущем, тем более что Postgres тоже не стоит на месте и развивается туда, куда ждут потребители, — в область поддержки ИИ (pgvector, например) или в сторону параллелизма вычислений. Если кто-то и бросает вызов, то в конкретных нишах — как, например, Lakehouse в аналитических задачах на больших объемах данных, — говорит Юлий Гольдберг, GlowByte.

Читать интервью эксперта GlowByte в РБК

JDBC, Hibernate, Spring Data, MyBatis, jOOQ — почему в Java столько способов работать с базами данных?

Разбираемся на бесплатном вебинаре «Java Persistence: обзор фреймворков для доступа к данным». В прямом эфире пройдём от низкоуровневых инструментов до высокоуровневых абстракций.

Программа:

☕ JDBC и Spring JDBC — основы работы с БД без абстракций.
☕ JPA и Hibernate — что такое ORM, persistence context и как это работает внутри.
☕ Spring Data JPA vs Spring Data JDBC — различия репозиториев и критерии выбора.
☕ MyBatis и jOOQ — почему выбирают SQL-центричные фреймворки ради полного контроля.
☕ Альтернативные реализации JPA — что кроме Hibernate.
☕ Reactive Data Access — когда нужен R2DBC, а когда достаточно JDBC.
☕ Как выбрать фреймворк — сценарии, компромиссы и рекомендации. 

📆 Когда: 31 августа в 16:00 (Мск)

🙍‍♂ Спикер: Александр Краснянский, эксперт в Java/Kotlin и архитектуре ПО

✍ Записаться

Что подтянуть бэкендеру для продакшена: 12 практических открытых уроков

Когда приложение выходит за пределы локальной машины, появляются задачи, которые редко помещаются в документацию одного фреймворка: блокировки, очереди, конкурентность, производительность и отказоустойчивость.

В подборке — бесплатные занятия, где эти проблемы разбирают через реальные инструменты и сценарии, с которыми бэкендер сталкивается в работе.

Очереди и надёжная доставка

• 26 августа, 20:00. «Работа с Kafka через библиотеку Kafka Clients». Записаться

• 17 сентября, 20:00. «RabbitMQ в Production: Transactional Outbox, идемпотентность и DLQ в ASP.NET Core». Записаться

Базы данных и конкурентный доступ

• 1 сентября, 20:00. «PostgreSQL 18: асинхронный I/O и io_uring на практике». Записаться

• 8 сентября, 20:00. «Борьба с блокировками в PostgreSQL: как достичь высокой параллельности при большой нагрузке». Записаться

• 16 сентября, 20:00. «Темпоральные данные в PostgreSQL 18: история и версии без триггеров». Записаться

Нагрузка и производительность

• 3 сентября, 20:00. «ASP.NET Core API под нагрузкой: как сделать сервис устойчивым к сбоям и росту трафика». Записаться

• 9 сентября, 20:00. «Go‑профилирование: как найти и исправить „тормоза“ в продакшене». Записаться

• 22 сентября, 20:00. «Горутины и каналы: под капотом (under the hood) и нюансы в продакшене». Записаться

HTTP и серверная разработка

• 21 сентября, 20:00. «HTTP‑сервер на чистой Java за 30 минут». Записаться

• 20 октября, 19:00. «Балансировка HTTP и L4 сервисов в Angie». Записаться

Продакшен и наблюдаемость

• 23 сентября, 20:00. «eBPF: рентгеновское зрение для production». Записаться

• 23 сентября, 20:00. «Узнайте, как использовать Patroni для управления высокодоступными кластерами PostgreSQL». Записаться

ЧТО ПОЧИТАТЬ БЭКЕНД‑РАЗРАБОТЧИКУ

Если удобнее разбираться в теме в своём темпе, собрали несколько практических материалов: про серверы, обновление стека, обработку ошибок и тонкости C++.

• «Создаём HTTP/2-сервер на C++ и хостим на нём свой сайт»

• «Миграция на Spring Boot 4 и Java 25: пошаговый план, чтобы обновиться и не уронить прод»

• «std::expected в C++23: гайд по миграции с исключений на функциональный error handling»

• «Move‑семантика в C++: пять задач, в которых легко ошибиться»

PostgreSQL WAL, fsync и p99 на NVMe: что ограничивает запись

Чтобы оценить PostgreSQL WAL, fsync и p99 на NVMe, смотреть нужно на время commit. На p99 влияют файловая система, метод синхронизации, защищённость кэша, RAID или виртуализация и профиль транзакций.

Какая операция WAL сильнее всего влияет на задержку commit?

При synchronous_commit=on задержку commit обычно определяет flush WAL на диск: PostgreSQL отвечает после локальной синхронизации. При синхронной репликации добавляется ожидание ответа standby, а блокировки, высокая загрузка CPU или сеть могут сильнее повлиять на результат и скрыть задержку накопителя.

От записи WAL до подтверждения клиенту

Задержка записи WAL PostgreSQL включает путь от WAL-буферов до диска: XLogFlush сбрасывает WAL до нужного LSN через ядро, файловую систему и контроллер. Изменённые страницы пишутся отдельно, поэтому связь с checkpoint проверяют по времени.

Какие гарантии должны оставаться одинаковыми в каждом тесте

Зафиксируйте synchronous_commit, fsync, full_page_writes, способ синхронизации, параметры монтирования и режим кэша. При fsync=off сбой повредит кластер. Сравнивайте p99 fsync на NVMe без смены гарантий.

Очереди, прошивка, температура и заполнение накопителя

Снимите nvme id-ctrl /dev/nvme0, nvme smart-log /dev/nvme0 и укажите тип подключения. Отчёт от 27 мая 2025 года: бенчмарк pg_test_fsync для PostgreSQL 16 показал 1643 мкс на fdatasync для Samsung 990 Pro с XFS и 24 мкс для Micron 7400 с PLP в другом стеке. Разница здесь между классами накопителей, а не между конкретными моделями.

Почему пиковые IOPS NVMe не предсказывают p99 fsync?

Пиковые IOPS достигаются при глубокой очереди, а синхронный WAL часто ждёт одиночный flush. Средняя пропускная способность скрывает редкие паузы кэша, прошивки или сборки мусора. При этом паспортный показатель помогает при первичном отборе, но не заменяет длительное измерение задержки fsync на том же стеке, где будет лежать pg_wal.

pg_test_fsync и fio при шаблоне, похожем на WAL

В той же файловой системе, что и pg_wal, запустите

pg_test_fsync -f /test/pgfs -s 30

затем fio на отдельном файле:

fio --name=wal --filename=/test/wal.fio --size=2G --rw=write --bs=8k --iodepth=1 --fdatasync=1 --runtime=300 --time_based --output-format=json+

Если при одинаковой нагрузке вместе растут задержка synchronous_commit и fio sync latency, проверяйте накопитель.

Как fsync проявляется в pgbench под управляемой нагрузкой

Создайте базу

pgbench -i -s 100 benc

и выполните по три 10-минутных прогона при N=1, 8 и 32:

pgbench -M prepared -c N -T 600 -l bench

По журналам рассчитайте p50, p95 и p99. Их рост вместе с задержкой fsync и очередью указывает на узкое место хранилища WAL.

Queue depth, await и редкие провалы NVMe

Параллельно снимайте iostat -x 1 и nvme smart-log. Рост await и aqu-sz вместе с пиками commit latency указывает на очередь. Но похожую картину даёт checkpoint, поэтому сопоставляйте метрики по времени и фиксируйте wal_sync_method.

Как правильно интерпретировать pg_test_fsync?

1. Сравнивайте методы на файловой системе будущего pg_wal.

2. Читайте полный вывод вместе с условиями теста.

3. Сверяйте результаты с pgbench и мониторингом: микротест не предсказывает p99 commit.

Что меняет профиль записи, а что меняет гарантию

При групповом commit один flush обслуживает несколько транзакций, поэтому throughput и queue depth меняются с конкуренцией. wal_sync_method выбирают по результатам теста. synchronous_commit=off грозит потерей подтверждённых транзакций: это другая гарантия сохранности, а не настройка производительности.

Как перевести измерения в требование к хранилищу

Например, SLO допускает до 1% транзакций дольше 10 мс и до 30 секунд непрерывного нарушения. Тест проводят при рабочем заполнении. После смены прошивки, файловой системы или хоста снова проверяют tail latency.

Хранилище выбирают по p99 commit при тех же гарантиях сохранности. PostgreSQL WAL, fsync и p99 на NVMe сопоставляют по времени: pg_test_fsync измеряет flush, pgbench его эффект, а iostat – состояние очереди.

Программа Tantor JAM 2026

10 сентября (чт) в Москве особое мероприятие для всех, кто интересуется передовыми решениями в области СУБД: компании «Тантор Лабс» исполняется пять лет. Мы приглашаем разработчиков СУБД, инженеров, архитекторов, администраторов, представителей заказчиков и партнеров, чтобы обсудить, куда движется российская инфраструктура данных и какие технологии уже сейчас меняют привычный подход к работе с Postgres-инфраструктурой.

Программа и регистрация

• Вадим Яценко, генеральный директор «Тантор Лабс»5 лет «Тантор Лабс».
  Российским СУБД пора играть по-крупному

• Алексей Барган, руководитель отдела разработки Платформы Tantor
  AI-first подход в управлении и администрировании СУБД. Как меняется профессия DBA?

• Семен Курепин, пресейл-инженер
  Платформа Tantor 7.0: Интеграция предиктивной аналитики в контур эксплуатации СУБД

• Екатерина Мартьянова, директор по продукту Tantor XData; Михаил Сёмкин, team lead СУБД Tantor Polar
  Машина баз данных Tantor XData Gen3: постгресовый дрифт в сторону enterprise

• Максим Милютин, руководитель группы исследований и разработки
  Нативная (без ETL) аналитика на оригинальных данных. PX-движок для Tantor Polar

• Александр Симонов, технический руководитель направления развития 1С
  Postgres для 1С: от «работает» к «быстро» — за два года

• Сергей Соловьев, разработчик СУБД Tantor Postgres
  Новая эпоха TDE

• Андрей Погудин, инженер
  Защита данных в Tantor Postgres

Программа и регистрация

«Это написал Клод» — комментарий из-за рубежа, и почему идее хранилища больше двадцати лет (даже если так было бы, то клод выпивая тонные кофе это всё родил ...)

Под англоязычной версией статьи про SQLite-провайдер на dev.to появился комментарий в духе «даже без "load-bearing" и тире через всё предложение видно, что это писал Клод». Не первый раз слышу что-то подобное, так что решил ответить не в комментариях, а отдельным постом заодно расскажу то, что давно собирался: откуда вообще взялась идея хранилища, на котором всё это стоит.

Сначала честно про долю ИИ

Не скрываю и не буду: текст статей да, пишу в паре с Клодом, я не копирайтер и не техрайтер по профессии. Но код библиотек другая история. Скелет и инженерные решения — мои, всегда были моими. Клод дописывает рутину поверх уже заданного паттерна, полирует, ловит ошибки, пишет тесты и комментарии. Изобретать архитектуру и решать неочевидные компромиссы — не его работа, это разные навыки, и Клод хорош ровно в первом, не во втором.

Показательный пример сам релиз 3.6.0: баги, которые в него вошли, нашёл не Клод, а реальная эксплуатация. Модель не может споткнуться о краевой случай, который проявляется только под живой нагрузкой с непредсказуемым вводом такое не ловится по аналогии с соседним кодом.

А теперь откуда это всё вообще взялось

Основная идея хранилища не изобретение последних месяцев. Первая версия появилась в 2004 году, когда я писал на Delphi за двадцать с лишним лет до того, как Клод вообще начал существовать.

Задача была дать объекту динамические поля на ходу, не фиксируя их жёстким классом заранее. Delphi для этого уже нёс нужный кусок RTTI (Run-Time Type Information): каждый класс несёт метаданные о своих полях и свойствах, доступные в рантайме, не только на этапе компиляции. Поверх этого интерфейс IDispatch из COM: GetIDsOfNames резолвит имя поля в DISPID, Invoke вызывает по этому DISPID, передавая значение через VARIANT. Вместе это давало то, чего не даёт обычный жёсткий класс: объект мог обзавестись полем, которого не существовало на момент компиляции, а вызывающая сторона спросить о нём по имени и получить настоящий типизированный ответ.

Система прожила у меня внутри собственных проектов много лет, никуда не публикуясь. За это время она полностью пережила Delphi и COM переехала на .NET, механизм сменился до неузнаваемости (никакого VARIANT, никакого DISPID сейчас это типизированные колонки в Postgres/MSSQL/SQLite, которые я уже разбирал построчно в статье про 13 таблиц), а вопрос остался ровно тем же: как дать объекту гибкий набор полей, не потеряв возможность спросить "а какого оно вообще типа".

Отсюда, кстати, и название RTTI-based storage, не маркетинговый термин, а прямое родство с тем самым механизмом Delphi. И не EAV там никогда не было обезличенной колонки "значение", RTTI всегда знало настоящий тип.

Клод помогал полировать это перед тем, как это увидело свет публично. Сама идея и её первое воплощение старше Клода на десятилетия.

Цикл про redb:

• redb — типизированное хранилище для .NET поверх Postgres/MSSQL: без миграций, без Include, с полным LINQ

• REDB изнутри, статья 1: 13 таблиц, на которых работает всё

• Анатомия SQLite-провайдера: уходим от EF Core — статья, под которой появился тот самый комментарий

Всё лежит в публичных репозиториях redbase-app. Предлагаю не гадать по стилю прозы, а склонировать к себе и прогнать нейронкой глубоко, очень глубоко. И приглашаю на дискуссию: если найдёте что-то, что выглядит как архитектурное решение именно от модели, а не от человека, который держит всю систему в голове годами с удовольствием обсужу предметно.

Пассажир меняет билет прямо в дороге — а маршрут собран из трёх GDS и ж/д. Что происходит с данными

Сотруднику нужно долететь до одного города, доехать поездом до другого, и обратно тем же путём — одна командировка, билеты из разных систем бронирования. А потом он уже в дороге пишет в телеграм: "планы изменились, летим не туда, перебронируй".

Три системы под самолёты — Amadeus, Sabre, Travelport: исторически несовместимые XML-диалекты одного и того же понятия перелёта, выросшие из мейнфреймов 60-80-х, каждый со своими причудами и полями, которых нет у соседа. Плюс отдельная, никак не связанная с ними система бронирования под железную дорогу — свой формат, своя логика мест и классов, ничего общего по структуре с авиационными GDS. Запросить всё это параллельно, свести разноформатные ответы в одно и собрать из них валидный маршрут по стыковкам — уже само по себе задача не для россыпи if и ручных мапперов.

А потом человек уже в дороге меняет одно плечо маршрута. Один перелёт уже случился — трогать нельзя. Один — впереди, подлежит замене. И весь маршрут не по шаблону "туда-обратно", а любой длины и состава: сегодня две пересадки, завтра — четыре, послезавтра прямо в дороге вставили лишний вылет.

Тут ломаются две разные вещи, и почти всегда решают только одну.

Первая — как описать саму логику поверх этого зоопарка источников. И сбор из четырёх систем разом, и ветка "можно менять / нельзя менять" превращаются либо в DSL на языке общепринятых интеграционных паттернов (Scatter-Gather, Content-Based Router — тот же словарь, что у Apache Camel), который прочитает и поймёт человек, ни разу его не писавший, — либо в код, который через полгода не восстановит и автор.

Вторая — куда положить результат. Маршрут — не два поля outbound/return, а последовательность разнотипных плеч (самолёт ≠ поезд), где число элементов и состав не известны заранее и меняются посреди собственной жизни объекта. Стандартный ответ — либо гора nullable-колонок под все виды транспорта разом, либо миграция на каждый новый вид.

Разбираю, что происходит, когда обе оси — читаемый DSL для потока и пластичная типизация для формы — закрывает один связный инструментарий, а не сшиваются вручную посередине, каждая своими костылями.

Скоро.

ссылки: хабр redb.ru

Приглашаем на вебинар «СУБД + AI: векторные операции, LLM и полиглотная архитектура в Digital Q.DataBase»

10 августа в 13:00 (мск) компания «Диасофт» проведет практический вебинар о новых возможностях 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)
);

Добавим данные для нескольких векторов разных объектов:

INSERT INTO items (title, embedding) VALUES
 ('PostgreSQL embeddings', '[0.10, -0.80, 0.45]'),
 ('Neural image processing', '[0.42, 0.18, -0.35]'),
 ('Sound pattern matching', '[-0.20, 0.70, 0.60]'),
 ('Document clustering', '[0.09, -0.79, 0.48]');

Теперь сравним их попарно и отсортируем по расстоянию:

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-адреса вашей реплики.

Откройте конфигурационный файл клиентской аутентификации:

nano /etc/postgresql/17/main/pg_hba.conf

Обратите внимание, что тут рассматривается настройка репликации на примере PostgreSQL 17.

Найти точное расположение файла можно в командной строке PostgreSQL с помощью команды SHOW:

sudo -u postgres psql -c "SHOW hba_file;"

Добавьте в pg_hba.conf следующую строку, указав вместо REPLICA_ВНУТРЕННИЙ_IP сетевой адрес вашего ведомого сервера:

host    replication    replicator    REPLICA_ВНУТРЕННИЙ_IP/32    scram-sha-256

Для доступа к реплицируемым данным у пользователя 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, где отказоустойчивость, репликация и обслуживание кластера уже реализованы на уровне платформы.

Это позволяет сократить операционные расходы на сопровождение инфраструктуры и снизить риск простоев критичных сервисов.

Где бэкенд начинает тормозить: 18 открытых уроков по языкам, данным и архитектуре

Бэкенд редко подводит из‑за одной очевидной ошибки. Сервис начинает медленно отвечать из‑за цепочки межсервисных вызовов, очередь перестаёт справляться с потоком событий, база упирается в пределы масштабирования, а проблемы с памятью или конкурентностью проявляются только под нагрузкой.

В августе и сентябре преподаватели OTUS проведут бесплатные уроки для бэкенд‑разработчиков. В программе — Python, Go, C# и JVM, микросервисная архитектура, PostgreSQL, брокеры сообщений, наблюдаемость и контейнеризация. Выбирайте свою тему и присоединяйтесь к практическим разборам.

Архитектура и взаимодействие сервисов

• 3 августа, 20:00. «Использование брокера сообщений Apache Kafka в распределённых очередях». Записаться

• 4 августа, 20:00. «Секреты межсервисных запросов: как сделать приложение быстрым и надёжным». Записаться

• 12 августа, 20:00. «Паттерны отказоустойчивости и масштабируемости микросервисной архитектуры». Записаться

• 13 августа, 20:00. «Управление данными в MSA — дыра в бюджете или актив для ИИ-трансформации?». Записаться

• 19 августа, 20:00. «Монолит или микросервисы? Руководство для архитекторов, которые ценят свои нервы». Записаться

• 24 августа, 20:00. «Основные шаблоны проектирования в системном дизайне». Записаться

Языки, память и конкурентность

• 3 августа, 20:00. «Go: управляем памятью как профи. Массивы, слайсы и мапы». Записаться

• 4 августа, 20:00. «Многозадачность в Python. Асинхронность, процессы, потоки». Записаться

• 5 августа, 20:00. «Битва нативных платформ: Spring Boot 4, Quarkus, Micronaut, KMP, Go и Rust». Записаться

• 18 августа, 20:00. «Python asyncio: gather, wait, TaskGroup на практике». Записаться

• 18 августа, 20:00. «Горутины и каналы: базовые принципы параллелизма в Go». Записаться

• 18 августа, 20:00. «Архитектурные ошибки, которые совершают даже опытные C#-разработчики». Записаться

Базы данных и работа с состоянием

• 11 августа, 20:00. «Работа с SQLAlchemy и Alembic в FastAPI». Записаться

• 19 августа, 20:00. «PostgreSQL на стероидах: большие данные, высокие нагрузки и масштабирование без боли». Записаться

• 1 сентября, 20:00. «PostgreSQL 18: асинхронный I/O и io_uring на практике». Записаться

• 16 сентября, 20:00. «Темпоральные данные в PostgreSQL 18: история и версии без триггеров». Записаться

Наблюдаемость и контейнеризация

• 4 августа, 20:00. «OpenTelemetry — наблюдаемость на блюдечке». Записаться

• 20 августа, 20:00. «Docker для Python-разработчика». Записаться

Что почитать перед практикой

1. Создаём HTTP/2-сервер на C++ и хостим на нём свой сайт
   _{Путь от чтения RFC и реализации обработчика запросов до запуска сервера в контейнере. Внутри — защита исполняемого файла, ограничения для HTTP/2, работа с облачными площадками и поиск утечки памяти в OpenSSL.}

2. std::expected в C++23: гайд по миграции с исключений на функциональный error handling
   _{Как сделать ошибку явной частью сигнатуры функции, выстраивать цепочки операций и постепенно внедрять std::expected в существующий проект.}

3. Move-семантика в C++: пять задач, в которых легко ошибиться
   _{Разбор ловушек, которые успешно компилируются, но приводят к лишним копированиям, замедлению программы или неопределённому поведению.}

4. Миграция на Spring Boot 4 и Java 25: пошаговый план, чтобы обновиться и не уронить прод
   _{План обновления рабочего сервиса с промежуточными этапами, автоматизированными проверками, канареечным развёртыванием и заранее подготовленным сценарием отката.}

JSON или XML: сравнение популярных форматов обмена данными

Выбор между JSON и XML редко стоит как «что лучше» — это два инструмента с разной философией. JSON оптимизирован под компактность и скорость парсинга, XML — под строгую структуру, валидацию и сложные документы со смешанным содержимым.

В статье разобрали оба формата на одинаковых примерах, прошлись по истории и причинам, по которым JSON вытеснил XML в вебе. Сравнили по ключевым параметрам: синтаксис, объем, скорость обработки, поддержка типов данных, комментарии, пространства имен, валидация через JSON Schema и XSD. И отдельно написали про области применения.

Подробности — в блоге Рег.облака.

Программирование с явно выделенным состоянием

Одна из моих любимых тем, про которую не устаю говорить. В модели данных часто бывает ситуация, когда состояние выражено не прямым образом, а косвенно. Буквально вчера я реализовывал кастомные тарифы под конкретных пользователей. Отличие такого тарифа от обычного сводится к тому, заполнено ли поле user_id в тарифе или нет. Если не заполнено, то значит это общий тариф, если заполнено, значит под конкретного пользователя и другие его не могут видеть.

Это вполне рабочая схема и она встречается повсеместно, особенно в связке с датами типа deleted_at, но она обладает одним очень важным недостатком. Понимание того, что эта запись находится в особом состояние вычисляется через косвенный признак или, что хуже, через набор признаков. Об этом надо думать и каждый раз вспоминать и выуживать эту информацию.

Сейчас, в эру агентного программирования, это стало еще важнее. Агент может догадаться до правила, но ему нужно на это время и отдельный анализ. Можно конечно написать об этом в правилах, но зачем, когда можно просто поправить модель данных? Все что требуется, это введение текстового поля со статусом, которое явным образом скажет о происходящем с этой записью.

В общем не полагайтесь на то как заполнены поля, вводите нужные статусы, которые явно будут говорить о том что происходит. Заодно это дает более удобную аналитику и выборки

Приглашаем на пятилетие «Тантор Лабс». 10 сентября - Tantor JAM 2026

Первый юбилей Tantor — пять лет с момента основания компании. За это время мы прошли путь от стартапа до технологического лидера, одного из ведущих российских разработчиков в области управления и хранения данных, создали собственную экосистему продуктов и собрали вокруг себя сообщество, которое сегодня во многом определяет развитие российского рынка СУБД.

Программу скоро представим. Среди главных премьер:

• Новое поколение Платформы Tantor, основанное на AI-first подходе. Представим ИИ-администратора БД с целым роем специализированных ИИ-агентов, которые возьмут на себя рутинные операции по работе с СУБД.

• Результаты испытаний МБД Tantor XData Gen3 на различных профилях нагрузки. Покажем, как enterprise-технологии, ранее доступные только в зарубежных решениях, — независимое масштабирование Compute и Storage, RDMA, распределенная файловая система и полноценный HTAP — становятся доступны в российском ПАКе.

• Подробнее расскажем о Tantor Polar — новой распределенной СУБД, открывающей следующий этап развития российских PostgreSQL-технологий с полным сохранением совместимости с экосистемой Postgres.

Вас ждут выступления руководителей разработки, общение с инженерами, архитекторами, заказчиками и партнерами, а также праздничная программа в честь пятилетия компании.

10 сентября 2026 года, Москва

Регистрация уже открыта.

Участие бесплатное (требуется подтверждение от организатора).

Вышла бесплатная книга к курсу «SQL Введение»

Всем привет!

Недавно я публиковал здесь бесплатный курс «SQL Введение» на платформе Stepik. За это время курс уже начали проходить более 400 студентов.

В продолжение курса я подготовил ещё один бесплатный материал — книгу, которая поможет изучать SQL ещё удобнее.

Бесплатный курс: https://stepik.org/a/290855

Зачем появилась книга

Во время обучения многим удобно иметь материал не только в формате уроков, но и в виде единого пособия, к которому можно быстро вернуться в любой момент.

Поэтому я решил подготовить книгу, полностью основанную на материалах курса. Она повторяет структуру уроков и позволяет легко закреплять пройденный материал.

Что представляет собой книга

Книга полностью соответствует программе курса и может использоваться параллельно с его прохождением.

Её можно использовать как:

• офлайн-версию курса для повторения материала;

• удобный конспект при выполнении практических заданий;

• справочник для быстрого повторения основных конструкций SQL.

Если вы уже проходите курс, книга поможет быстрее находить нужную информацию и возвращаться к темам, которые хочется повторить.

Для кого она будет полезна

Так же, как и сам курс, книга ориентирована на тех, кто только начинает знакомство с SQL:

• студентов IT-специальностей;

• начинающих разработчиков;

• будущих аналитиков данных;

• тестировщиков;

• всех, кто хочет разобраться в основах работы с реляционными базами данных.

Бесплатный доступ

Книга распространяется бесплатно.

Если вы проходите курс «SQL Введение», она уже доступна внутри курса в качестве дополнительного учебного материала.

Кроме того, книга опубликована на GitHub, где всегда можно скачать последнюю актуальную версию.

https://github.com/Awilum/sql-introduction

Чтобы скачать последнюю актуальную версию, перейдите в раздел Releases, где всегда доступен самый свежий выпуск книги. 

https://github.com/Awilum/sql-introduction/releases

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

В предыдущих видео я рассказывал о том, как Digital Q.DataBase воспроизводит функциональность Microsoft SQL Server, позволяя переносить приложения без переписывания прикладной бизнес-логики. Мой коллега Илья Лебедев также подробно рассказал о возможностях воспроизведения функциональности Oracle и подходах к миграции Oracle-приложений.

В этом докладе Илья Виссарионов рассказывает о практическом опыте компании «Диасофт» по импортозамещению крупной автоматизированной банковской системы, которая десятилетиями работала на 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 и других зарубежных решений.
Платформа позволяет сохранить существующие инвестиции в прикладной код и значительно сократить трудозатраты при миграции информационных систем.

🔹 Бесплатное получение дистрибутива: https://database.diasoft.ru/?utm_source=andrei
🔹 Документация: доступна внутри дистрибутива  
🔹 Telegram-сообщество Digital Q.DataBase: https://t.me/dqdatabase   
🔹 MAX: https://max.ru/join/orlthIssLJbjj37mjlEEYARWFyuJk5yMixLlGPISIzc

Как мы воспроизводим функциональность 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 и других зарубежных решений.
Платформа позволяет сохранить существующие инвестиции в прикладной код и значительно сократить трудозатраты при миграции информационных систем.

🔹 Бесплатное получение дистрибутива: https://database.diasoft.ru/?utm_source=andrei
🔹 Документация: доступна внутри дистрибутива  
🔹 Telegram-сообщество Digital Q.DataBase: https://t.me/dqdatabase   
🔹 MAX: https://max.ru/join/orlthIssLJbjj37mjlEEYARWFyuJk5yMixLlGPISIzc

Новости мира Datalakehouse - DWH: на 26.06.26

"гонка сместилась к ИИ-агентам"

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

Сначала про слово, которое будет дальше. Lakehouse - это подход, когда вся аналитика компании живёт в одном общем хранилище поверх дешёвых файлов, без отдельной дорогой базы под отчёты. Дальше речь о том, что с этим подходом случилось за полгода.

Databricks (их большая конференция прошла 16 июня). Показали новый движок Lakehouse//RT - он обещает выдавать аналитику почти мгновенно прямо из общего хранилища, без отдельной быстрой базы под витрины. Пока это ранняя версия и работает только на чтение, то есть данные через него можно читать, но не записывать. Второй анонс - способ держать «живые» рабочие данные и аналитику в одном месте, без постоянной перекачки между системами (обычно компании гоняют данные туда-сюда ночными выгрузками). Третий, и самый показательный - набор инструментов, чтобы пускать к данным ИИ-агентов: объяснять программе смысл данных и контролировать, куда ей можно лезть, а куда нет.

ClickHouse (своя конференция 27 мая). Это очень быстрая база для аналитики. Они запустили собственную управляемую версию Postgres - популярной базы, на которой работают тысячи приложений, - и научили её мгновенно отдавать все изменения в аналитику, без задержек. Плюс добавили ИИ-агентов поверх данных, построенных на Claude. По деньгам у них всё хорошо: годовая выручка за год утроилась и перевалила за 250 миллионов долларов.

Snowflake. Открыли свой каталог данных Polaris - это, грубо говоря, общее оглавление всех таблиц, по которому разные программы понимают, где что лежит. Раньше он был только их, теперь его передали в открытый фонд Apache, чтобы пользоваться им могли любые инструменты. А популярный открытый формат таблиц Iceberg дорос до новой версии и научился хранить более сложные данные.

SAP покупает компанию Dremio (сделка ещё не закрыта). Крупный вендор корпоративного софта докупает технологию, чтобы собрать собственное хранилище нового типа под ИИ. Это часть общего движения: рынок сходится вокруг одного открытого формата данных - того самого Iceberg.

DuckLake дорос до версии 1.0. Маленький и нарочно простой проект: он хранит оглавление данных в обычной знакомой базе (Postgres), а не в куче разрозненных служебных файлов, как делают старшие конкуренты. Меньше магии - проще обслуживать.

Если совсем коротко: скорость никуда не делась, её даже больше. Но она перестала быть главным козырем и стала фундаментом. Поверх неё все теперь строят слой управления ИИ-агентами - как объяснить программе смысл данных и как не пустить её туда, куда нельзя. По сути это ровно то, чем администраторы баз данных занимаются уже много лет, просто теперь у этого модные названия.

Дальше разберу каждый анонс по отдельности. Ждите продолжения.

Подъехало продолжение:

Databricks (их большая конференция прошла 16 июня) - ссылка на подробный разбор

ClickHouse (своя конференция 27 мая) - ссылка на подробный разбор