D
Data Chaos
@data_chaos129 подп.
211просмотров
13 ноября 2025 г.
Score: 232
Хочу обратить внимание на статью, которой поделился наш коллега по цеху https://topicpartition.io/blog/postgres-pubsub-queue-benchmarks И набирающий популярность подход: Just Use Postgres (for everything) Ключевые мысли: 🔹 «Small Data + Big Hardware» — современное железо тянет больше, чем кластер из 6 брокеров. 🔹 90 % компаний не Google-масштаб. 🔹 Kafka даёт избыточную сложность там, где Postgres просто «insert into да и х с ним». 🔹 Современный Postgres решает 80 % задач Redis, Mongo и Kafka одновременно. 🔹 Репликация - единственный настоящий bottleneck, а не база. На самом деле, это интересный mind shift, так как все мы привыкли юзать дефолтные инструменты "потому что так исторически сложилось". Вот такой результат даёт малыш на 4 vCPU single node🚀: write message rate: 5036 msg/s write throughput: 4.8 MiB/s write latency: 38.7ms p99 / 6.2ms p95 read message rate: 25,183 msg/s read message throughput: 24.6 MiB/s read latency: 27.3ms p99 (varied 8.9ms-47ms b/w runs); 4.67ms p95 end-to-end latency5: 60ms p99 / 10.6ms p95 server kept at ~60% CPU; Согласитесь - неплохо. И такой маленький инстанс (с масштабируемостью) закрывает практически 95% современных дата пайплайнов (если вы не Убер или Гугл). Единственная проблема, которую надо решить - диски с хорошим I/O. Парадокс избыточного дизайна Архитекторы переоценивают требования («Google-scale mindset»), тратя ресурсы на сложность вместо устойчивости. ✅ Подходит когда: -объёмы (< 100 K msg/s); -low-latency-пайплайны; -когда нужна простота и консистентность. 🧭 Итог Kafka - отлична. Но Postgres + современное железо + здравый смысл часто дешевле, надёжнее и быстрее. Строит начать задавать себе вопросы при проектировании "Окей, а мы можем использовать только PG?"
211
просмотров
1737
символов
Да
эмодзи
Нет
медиа

Другие посты @data_chaos

Все посты канала →
Хочу обратить внимание на статью, которой поделился наш колл — @data_chaos | PostSniper