Зачем нужен 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
Picodata выросла из форка Tarantool, но это самостоятельная СУБД: свой планировщик распределённых запросов, свой кластер-менеджер на Raft, PostgreSQL как основной протокол и расширение плагинами на Rust. Разбор устройства на живом кластере — репликасеты, бакеты, тиры — и что происходит с ответами на запросы, когда узлы выходят из строя
Обслуживание хранилища PostgreSQL: declarative partitioning (range/list/hash), MVCC и природа bloat, тюнинг autovacuum, VACUUM против VACUUM FULL и pg_repack, transaction ID wraparound и freeze, мониторинг раздувания таблиц
Инфраструктурный пулер перед PostgreSQL: почему соединения дорогие, режимы session/transaction/statement pooling, PgBouncer против pgcat (шардинг, балансировка), подводные камни transaction pooling (prepared statements, SET) и где ставить пул
Ближайшие материалы, которые продолжают этот раздел.
Вводный материал про Redis как класс решений: паттерны, анти-паттерны, ограничения и подходы к надёжности.
Практический baseline для PostgreSQL в контейнерах: volume, backup, healthcheck и границы допустимого production.
Разбор dev- и lab-сценариев для ClickHouse и того, где контейнеризация уже начинает мешать эксплуатации.
