Real-Time базы данных

Uber показывает водителя на карте - он движется в реальном времени. Ни один HTTP-запрос не успеет за этим. Как сотни тысяч экранов одновременно получают свежие координаты без единого polling?

• **Firebase Firestore** держит более 5 миллионов одновременных WebSocket-соединений в пике - каждый клиент получает push при изменении своих данных без единого poll
• **Supabase Realtime** используется в collaborative tools типа Notion-клонов: каждый INSERT в таблицу `blocks` мгновенно появляется у всех участников через PostgreSQL WAL
• **MongoDB Change Streams** в Confluent-стеке позволяет стримить изменения коллекций напрямую в Kafka - без ETL, без задержки batch-окна
• **PlanetScale + Ably**: компании на Vitess/MySQL добавляют realtime через managed WebSocket-слой - БД не меняется, добавляется только pub/sub прокси

Firebase Realtime Database и Firestore

Firebase предлагает два продукта с push-уведомлениями: **Realtime Database** (RTDB) - JSON-дерево с WebSocket-синхронизацией - и **Firestore** - документная БД с более гибкими запросами. Оба работают по одной модели: клиент подписывается на путь/коллекцию, сервер пушит дельты при каждом изменении. Никакого polling, никакого Long-polling - чистый WebSocket.

Firestore держит более **5 миллионов одновременных подключений** в пиковые периоды. Под капотом - проприетарная инфраструктура Google с regional endpoints и автоматическим failover. Разработчик видит лишь `onSnapshot()` - остальное абстрагировано.

**Realtime Database vs Firestore:** RTDB - одна большая JSON-структура, дешевле для простых чатов, но сложные запросы невозможны. Firestore - коллекции/документы, поддерживает составные индексы и queries. Для новых проектов Google рекомендует Firestore. RTDB остаётся в строю для legacy и ultra-low-latency write scenarios.

• **onSnapshot()** - подписка на документ или коллекцию с фильтром
• **Offline persistence** - SDK кеширует данные локально, синхронизирует при восстановлении сети
• **Security Rules** - декларативные правила доступа на уровне путей/документов
• **Pricing per read** - каждое чтение через listener считается как document read

Supabase Realtime через PostgreSQL

Supabase Realtime - надстройка над обычным PostgreSQL. Никакой специальной БД: берётся стандартный механизм **LISTEN/NOTIFY** из Postgres, оборачивается в WebSocket-сервер (написан на Elixir/Phoenix), и клиент получает события изменений таблиц.

Архитектура: PostgreSQL WAL (Write-Ahead Log) -> logical replication -> Supabase Realtime сервер -> WebSocket -> клиент. Каждый INSERT/UPDATE/DELETE в отслеживаемой таблице превращается в событие. Это означает: **любая существующая PostgreSQL БД** может стать realtime, без смены движка.

**Как включить:** в Supabase нужно выполнить `ALTER TABLE orders REPLICA IDENTITY FULL` - без этого UPDATE/DELETE не будут содержать старые значения строки. По умолчанию REPLICA IDENTITY = DEFAULT (только primary key). FULL - передаёт всю строку в WAL, что нужно для полного payload в событиях.

• **Broadcast** - произвольные события между клиентами одного channel (без записи в БД)
• **Presence** - отслеживание онлайн-статуса пользователей в channel
• **postgres_changes** - события из WAL PostgreSQL с фильтрацией по таблице/строке
• **RLS** - Row Level Security применяется к realtime-событиям автоматически

RethinkDB и MongoDB Change Streams

**RethinkDB** - документная NoSQL БД, уникальная тем, что строила realtime как **первоклассную фичу**, а не надстройку. Концепция называется **changefeed**: вместо обычного запроса `r.table('orders').run()` пишется `r.table('orders').changes().run()` - и курсор не закрывается, а продолжает отдавать строки при каждом изменении таблицы.

RethinkDB закрыта в 2016 году (Stripe, один из главных инвесторов, отказался от финансирования). Проект открыт под Apache License и поддерживается сообществом, но активная разработка остановлена. Это важный исторический пример: правильная идея может провалиться из-за рынка, а не технологии.

**MongoDB Change Streams** - живой наследник идей RethinkDB. Работает через oplog (журнал операций replica set), поддерживает aggregation pipeline для фильтрации, resumeToken для восстановления после разрыва соединения. Требует replica set даже для development - standalone MongoDB Change Streams не поддерживает.

Как выбирать realtime-БД

Выбор realtime-БД зависит от нескольких осей: **существующий стек**, **масштаб**, **vendor lock-in tolerance** и **тип данных**. Нет универсального ответа - есть trade-offs, которые нужно осознанно принять.

• **Уже используется PostgreSQL** - Supabase Realtime или самостоятельный LISTEN/NOTIFY. Нет новой инфраструктуры, SQL-запросы остаются, RLS из коробки.
• **Уже используется MongoDB** - Change Streams. Требует replica set, зато aggregation pipeline для фильтрации даёт гибкую серверную фильтрацию.
• **Стартап, скорость важнее контроля** - Firebase Firestore. Managed, масштабируется до 5M+ соединений, SDK для всех платформ. Цена за reads растёт линейно.
• **PlanetScale / Vitess** - горизонтальное шардирование MySQL без нативного realtime. Нужен дополнительный слой (например, Ably или Pusher).
• **Self-hosted + open source** - Supabase self-hosted или Electric SQL для Postgres-based realtime.

Общий принцип: **не строить realtime поверх БД, которая для этого не предназначена**. Добавление polling или самописных triggers к обычному MySQL - источник скрытых ошибок и производительных проблем под нагрузкой. Лучше выбрать правильный инструмент или добавить dedicated realtime-слой (Ably, Pusher, собственный WebSocket-сервер с Redis pub/sub).

1. Определить тип данных: реляционные (Supabase), документы (MongoDB Change Streams), graphy (Firebase с вложенными JSON)
2. Оценить vendor lock-in: Firebase = полная зависимость от Google, Supabase = можно self-host
3. Посчитать стоимость при целевом масштабе: Firebase billing per-read быстро растёт при > 100k MAU
4. Проверить требования к запросам: нужны сложные joins? - Supabase. Простые документы? - Firebase или MongoDB.

Итоги

• **Firebase Firestore** (`onSnapshot`) - проприетарный realtime через WebSocket, масштабируется до 5M+ соединений, billing per-read растёт с трафиком
• **Supabase Realtime** строится на WAL PostgreSQL + logical replication - обычная реляционная БД получает push-семантику без смены движка
• **RethinkDB changefeeds** - первая БД с realtime как first-class фичей, закрыта в 2016 по бизнес-причинам; идея живёт в MongoDB Change Streams
• Выбор realtime-БД: сначала проверить нативные возможности существующего стека (LISTEN/NOTIFY, Change Streams), только потом рассматривать миграцию

Связанные темы

Realtime БД - один слой системы. Вокруг него есть транспорт, кеширование и обработка потоков:

• WebSocket протокол — Транспортный уровень для всех realtime БД - Firebase, Supabase и MongoDB Change Streams доставляют события через WebSocket-соединения
• Redis Pub/Sub — Горизонтальное масштабирование WebSocket-серверов: несколько инстансов синхронизируют события через Redis, чтобы клиент на любом сервере получил своё событие
• Event-Driven Architecture — Realtime БД - источник событий в EDA-системах: Change Streams или LISTEN/NOTIFY триггерят обработчики, которые обновляют другие сервисы

Вопросы для размышления

• Суpabase Realtime работает поверх обычного PostgreSQL. Почему тогда не все команды используют его вместо Firebase, если PostgreSQL уже есть в большинстве проектов?
• RethinkDB закрылась, хотя технически была сильнее конкурентов в своей нише. Какие факторы кроме технического качества определяют выживаемость БД на рынке?
• При 1 миллионе одновременных подписчиков на одну таблицу - как Supabase Realtime сервер справляется с fan-out? Что может стать узким местом?

Связанные уроки

• db-19-redis