Разложить данные по узлам — самая простая часть. Дальше начинается счёт: запрос без ключа шардирования идёт во все шарды, join между по-разному распределёнными таблицами Citus по умолчанию вообще отказывается планировать, глубокая страница тащит с шардов сотни тысяч строк ради двадцати, а добавленный узел сам по себе не берёт на себя ни одного шарда. Всё — замерами на живом кластере Citus
Write-ahead logging как фундамент надёжности: сначала журнал, потом данные; durability и crash recovery (redo/undo), checkpoints, fsync и group commit — и во что обходится эта гарантия и что она покупает
Как одна задача — сгенерировать UUIDv7/ULID/Snowflake — решается в Go, Java и Rust (и почему ops/sec между языками сравнивать нельзя), как типы колонок PostgreSQL (uuid/bytea/text) обходятся с этими значениями и как ::text-каст ломает индекс, и как согласовать идентификатор с ключом шардирования, чтобы монотонный ключ не устроил горячий узел.
Случайный ID (UUIDv4) деградирует вставку в PostgreSQL: ниже плотность листьев B-tree, больше WAL, крупнее первичный индекс — измерено на стенде против bigint и монотонного UUIDv7. Плюс кросс-движковый разбор: миф «UUID-PK раздувает вторичные индексы» верен для MySQL/InnoDB и неверен для PostgreSQL; и когда монотонный ключ создаёт горячий шард (MongoDB ranged), а когда нет (ScyllaDB и Mongo hashed).
Карта выбора аналитической БД по нишам: масштабная аналитика на ClickHouse, аналитика и time-series внутри экосистемы PostgreSQL на TimescaleDB, встроенная локальная аналитика на DuckDB — с учётом стоимости и эксплуатации
Интеграционные тесты Go-сервиса шли 22 минуты и случайно падали по таймауту — списывали на медленную машину. Причина оказалась арифметической: 266 вызовов тестового хелпера поднимали 266 контейнеров Postgres. Разбираем переход на один контейнер и CREATE DATABASE … TEMPLATE, замеры до и после (×10 и ×36), воспроизводимый стенд, границы приёма — права, FORCE, размер шаблона, параллельность пакетов — и честную границу между тем, что измерено, и тем, что осталось правдоподобной гипотезой
Надёжность работы с PostgreSQL из приложения: пулы соединений, timeout, reconnect, чтение с реплик, failover, pgbouncer и аналоги — на Go, Java и Rust
Слои доступа к данным на JVM: сырой JDBC, ORM (JPA/Hibernate), типобезопасный SQL (jOOQ), Spring Data и Kotlin Exposed — что выбрать под задачу и где ORM создаёт больше проблем, чем решает
Чем OLAP-нагрузка отличается от OLTP, как колоночное хранение и векторное исполнение делают ClickHouse быстрым на аналитике, в какой момент PostgreSQL перестаёт тянуть агрегаты по большим таблицам — и где ClickHouse категорически не подходит
Что делать и чего избегать с индексами: over-indexing и write-amplification, неиспользуемые и дублирующие индексы, bloat и обслуживание, covering под горячие запросы, online-создание без блокировок, индексы под пагинацию — и антипаттерн «индекс на всё»
