Summarized from: https://topicpartition.io/blog/postgres-pubsub-queue-benchmarks

  1. The tech world is divided into two camps: one chasing buzzwords and adopting popular but potentially inappropriate solutions, and the other prioritizing common sense, pragmatism, and first principles.
  2. The “common sense” camp is gaining traction due to the “Small Data” movement (acknowledging sufficient hardware for most data sizes) and the “Postgres Renaissance” (Postgres’ growing capability to handle diverse use cases).
  3. The article argues that Postgres can effectively handle many functionalities typically assigned to specialized systems like Elasticsearch, MongoDB, Redis, and Kafka, covering over 80% of use cases with 20% of the effort.
  4. Benchmarks were conducted for Postgres as a Pub/Sub messaging system, demonstrating competitive performance with Kafka at lower scales (e.g., 5 MB/s ingest, 25 MB/s egress on a 3-node cluster).
  5. Postgres Pub/Sub performance scaled significantly on a 96 vCPU single node, achieving 238 MiB/s write and 1.16 GiB/s read throughput, though a custom design approach was used.
  6. Benchmarks for Postgres as a Queue also showed strong performance, with a modest single-node setup handling thousands of messages per second and an HA setup exceeding 2000 messages/second.
  7. The author advocates for defaulting to Postgres, emphasizing the quality-of-life benefits and reduced organizational complexity compared to specialized distributed systems for small-to-medium scale.
  8. Premature optimization by adopting complex web-scale technologies for non-web-scale problems is deemed an “anti-pattern” due to significant organizational and financial overhead.
  9. The “Minimum Viable Infrastructure (MVI)” approach is recommended: choosing familiar, “good-enough” technology, solving real problems with minimal features, and leveraging widely adopted systems like Postgres.
  10. The “it won’t scale” argument is refuted by citing OpenAI’s successful use of unsharded Postgres for massive read loads, the long timeframe for reaching critical scale, and the concept of overdesign.