Когда SQL не хватает, Picodata расширяют плагином на Rust: сервис внутри кластера со своим жизненным циклом, миграциями схемы и обновлением версий без остановки. Разбор на рабочем плагине — от скелета через pike до blue-green, включая места, где всё это ведёт себя не так, как ожидаешь
Как Picodata исполняет SQL на кластере: план, адресация к бакетам, двухфазная агрегация и motion — перенос данных между узлами. Почему соединение по ключу шардирования обходится без переноса, а обычное на объёме просто не выполняется, и откуда берутся два лимита, в которые упирается всё
PostgreSQL-протокол — основной способ работы с Picodata: psql, pgx и psycopg подключаются к ней тем же кодом, что к PostgreSQL. Но совместимость частичная, и граница проходит не там, где ожидаешь. Живая матрица пяти клиентов против 59 SQL-конструкций, поведение pg_dump и мигратора, и почему у Picodata собственный JDBC-драйвер
Picodata выросла из форка Tarantool, но это самостоятельная СУБД: свой планировщик распределённых запросов, свой кластер-менеджер на Raft, PostgreSQL как основной протокол и расширение плагинами на Rust. Разбор устройства на живом кластере — репликасеты, бакеты, тиры — и что происходит с ответами на запросы, когда узлы выходят из строя
Практика индексов: селективность и кардинальность, покрывающие индексы и index-only scan, составные индексы и порядок колонок, частичные и функциональные, и главное — почему индекс НЕ используется и как это увидеть
Два подхода к работе с SQL в Go без ORM на одном домене: sqlc генерирует типизированный код из SQL, а SQL-builders (squirrel, goqu) конструируют запросы программно. Где каждый силён, где кусается и как их комбинировать
ORM в Go: где такой подход оправдан, чем GORM отличается от EF/Hibernate, когда практичнее SQL-first go-jet, и какие есть альтернативы (sqlc, ent, bun)
