И на сегодня последнее про Postgres 😅
Посмотрел
интервью с автором книги
Just Use Postgres Denis Magda про то, как он начал работать с Postgres и написание книги.
Postgres стал его первой реляционной базой после университета, хотя в 2009 году все использовали MySQL из LAMP стека.
Он попал в компанию, которая строила высоконагруженную соцсеть, и DBA настояли на Postgres — уже тогда они крутили его в шардированной конфигурации с multi-writer setup через application-level sharding.
Потом он работал в Yugabyte, где большую часть времени исследовал и говорил про vanilla Postgres.
Когда начал копать глубже, понял, что почти не знает эту базу — только реляционную часть с joins и транзакциями.
Оказалось, что Postgres эволюционировал в general purpose database с расширениями, современным SQL, window functions, CTEs, JSON и кучей других возможностей.
На конференциях люди удивлялись, когда он рассказывал, что умеет Postgres.
Не было единого ресурса, где это всё было бы собрано.
Книгу писал полтора года, с июля 2024 по ноябрь 2025.
Идея созрела в 2023 году — сначала думал про YouTube туториал, но решил, что книга лучше подойдёт.
В каждой главе практические примеры, которые можно воспроизводить локально.
В интервью разобрали, когда Postgres может заменить Kafka.
Denis с коллегой Hubert Lubaczewski сделали бенчмарк — simple queue на одной ноде C7i.xlarge выдавал 5000 сообщений в секунду на запись. Для fan-out очереди, где каждое сообщение читается несколько раз разными консьюмерами, получили 5000 msg/s на запись и 25000 msg/s на чтение с 5x read rate. Всё на чистом SQL, 40-100 строк кода с блокировками через отдельную таблицу для сохранения порядка.
Отдельно обсудили аналитику в Postgres.
Denis выделил три подхода для работы с аналитическими workload'ами.
Первый — Postgres как columnar store через расширения типа TimescaleDB, когда можно загрузить данные, использовать компрессию и колоночное хранилище прямо в Postgres.
Второй — Postgres как query engine с расширениями вроде pg_duckdb или pg_lakehouse, которые позволяют запрашивать данные из lake house напрямую через Postgres, не выходя из привычного окружения.
Третий — Postgres просто как ETL провайдер, как делает Superbase ETL или Neon с Databricks, когда данные стримятся в lake house типа S3 в формате Parquet, а дальше используешь инструменты, созданные для этого storage.
Интересный момент про покупки — Databricks купили Neon, Snowflake взяли Crunchy, ClickHouse запустили свой Postgres offering.
Все они хотят владеть транзакционным слоем данных, потому что каждый lake house нуждается в транзакционных данных.
Если ты владеешь клиентами, которые используют Postgres для transactional workloads, то легко можешь переместить их данные в свой lake house и продать им аналитические решения.
Это становится твоей экосистемой от начала до конца.
@five_minutes_of_data
