CockroachDB говорит на протоколе PostgreSQL, но внутри устроен иначе: единое отсортированное KV-пространство, нарезанное на диапазоны, у каждого своя Raft-группа и свой арендатор. Разбираем слой за слоем на живом кластере: как 700 000 строк превращают один диапазон в шесть, чем арендатор отличается от Raft-лидера и что видит клиент, когда арендатор его данных внезапно гаснет.
Две стороны эксплуатации Picodata, проверенные на стенде: встроенный веб-интерфейс и экспорт метрик Prometheus включаются одним флагом, но кластерная в них только часть — остальное принадлежит опрошенному инстансу; и что происходит с кластером при добавлении узлов
История с прода: мониторинговая БД Zabbix распухала так, что VACUUM FULL приходилось гонять раз в две недели. Перевод history/trends на гипертаблицы TimescaleDB меняет саму модель удаления — построчный DELETE становится drop_chunks, — а нативная компрессия отдаёт место. Плюс неочевидная ловушка: когда порог сжатия совпадает с окном ретеншна, самая большая таблица не сжимается никогда.
Зачем нужен distributed SQL — горизонтальный масштаб с сохранением SQL и ACID-транзакций, как под капотом работают шардинг и консенсус (Raft у трёх движков, Paxos у OceanBase), чем платим латентностью распределённых транзакций и когда это оправдано против одиночного PostgreSQL с репликами. Все числа сняты на одном стенде: четыре движка, одинаковые замеры, назначенная задержка между узлами
Когда SQL не хватает, Picodata расширяют плагином на Rust: сервис внутри кластера со своим жизненным циклом, миграциями схемы и обновлением версий без остановки. Разбор на рабочем плагине — от скелета через pike до blue-green, включая места, где всё это ведёт себя не так, как ожидаешь
Две школы хранения временных рядов — PostgreSQL с гипертаблицами TimescaleDB и метрические движки Prometheus и VictoriaMetrics — на одном стенде: как continuous aggregate отстаёт от свежих и опоздавших данных и стирает историю после ретеншна, во что обходятся точка и ряд в каждой системе и почему increase() в Prometheus и VictoriaMetrics отвечает по-разному
Как Picodata исполняет SQL на кластере: план, адресация к бакетам, двухфазная агрегация и motion — перенос данных между узлами. Почему соединение по ключу шардирования обходится без переноса, а обычное на объёме просто не выполняется, и откуда берутся два лимита, в которые упирается всё
SQLite — не игрушка и не «база для мобилок»: это самая распространённая БД в мире, которая всё чаще стоит в проде на бэкенде. На стенде с тремя плечами — где single-file БД в процессе бьёт отдельный Postgres по латентности (больше порядка величины даже без сети — 12.6–19.1 раза по кругам замера) и простоте деплоя, а где нет: на честной, полностью долговечной записи fsync выравнивает всех, и SQLite на ней слегка проигрывает, а один писатель на файл — жёсткий потолок конкурентной записи. Плюс как не потерять данные (WAL-режим, litestream, репликация) и чем embedded-семейство отличается — SQLite, DuckDB для аналитики, встраиваемые KV (RocksDB/BadgerDB)
PostgreSQL-протокол — основной способ работы с Picodata: psql, pgx и psycopg подключаются к ней тем же кодом, что к PostgreSQL. Но совместимость частичная, и граница проходит не там, где ожидаешь. Живая матрица пяти клиентов против 59 SQL-конструкций, поведение pg_dump и мигратора, и почему у Picodata собственный JDBC-драйвер
Чтение EXPLAIN (ANALYZE, BUFFERS) на практике: seq scan против index и bitmap scan, типы индексов (btree/GiN/GiST/BRIN), статистика и планировщик, частые антипаттерны (функции по колонке, OR, N+1) и поиск тяжёлых запросов через pg_stat_statements
Ближайшие материалы, которые продолжают этот раздел.
Вводный материал про Redis как класс решений: паттерны, анти-паттерны, ограничения и подходы к надёжности.
Практический baseline для PostgreSQL в контейнерах: volume, backup, healthcheck и границы допустимого production.
Разбор dev- и lab-сценариев для ClickHouse и того, где контейнеризация уже начинает мешать эксплуатации.
