July 6, 2026
Postgres vs the tool hoarders
Do you really need separate systems when you already have Postgres?
Why juggle seven tools when one trusty database might already do the job
TLDR: The article argues most companies add far too many separate tools when Postgres, a popular database, can already handle much of the work. Commenters split between cheering the simpler setup and warning that stuffing everything into one system may just create a different kind of late-night headache.
A spicy little internet manifesto has kicked off a familiar tech food fight: why are so many teams piling on extra tools when plain old Postgres might already be enough? The article’s argument is basically, “Stop building a Rube Goldberg machine for a problem the boring, reliable thing can already handle.” And the crowd? Oh, they had feelings. Lots of them. One camp cheered the message like it was a long-overdue intervention for startups addicted to shiny new systems. The loudest applause came from people praising Postgres not just as dependable, but as refreshingly unrestricted too, with one commenter throwing shade at newer rivals for licenses that feel too controlling around big cloud companies.
But this was not a full-on love fest. The skeptics showed up fast with the classic “easy for you to say until the 2 a.m. emergency call” energy. One commenter asked the question that instantly cut through the hype: if you cram every extra feature into Postgres through add-ons, is that really simpler than using a separate tool built for the job? In other words, have you reduced chaos… or just moved it into a different closet?
And then there was the delightful absurdist wing of the thread. One person posted a string of wild Postgres projects that basically made it sound like the database is trying to become an operating system, GitHub, and artificial intelligence model all at once. Another lamented that one supposed MongoDB replacement still can’t match a beloved file-storage feature. Translation: the dream of one tool to rule them all is seductive, but the comments made one thing clear: the real drama is deciding when “good enough” is genius and when it’s just future pain in disguise.
Key Points
- •The article argues that many software teams adopt too many databases and microservices too early.
- •examples in the article include adding Redis, Elasticsearch, Sidekiq, MongoDB, Snowflake, and Kafka for separate tasks.
- •It says each additional system increases operational overhead through extra deployment, backup, monitoring, patching, and debugging requirements.
- •The article argues that most projects never reach the scale that would justify highly specialized, multi-system architectures.
- •It concludes that teams should only add specialized infrastructure after verifying that Postgres cannot meet their requirements and after accepting the ongoing operational cost.