Loading today’s stories
Build1 distinct publisher3 min readUpdated
A dev.to account of retiring Mongo, Redis, Elasticsearch and a vector store makes its strongest argument on consistency rather than cost, and it arrives without a single figure.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
The load-bearing part of this account is not the cloud bill, and the author says as much: what settled it was a consistency argument he credits to Tacnode's Alex Kimball, writing in March 2026, under the name Retrieval Gap [7]. One decision that reads the cache, the search index, the document store and the vector index composes up to four read timestamps, and the state it acts on may never have existed at any single moment [15]. That failure does not page anyone. It arrives as a support ticket about a stale result, which is how it survives years of green dashboards.
Keep the provenance in view while you take the mechanism: the phrase comes from a database vendor, in a post the author quotes rather than tests.
The feature planks under the all-Postgres case are of very different ages. Queues on SELECT ... FOR UPDATE SKIP LOCKED, via pg-boss on Node and River on Go, is the settled one, and it is what removes the case for standing up Kafka to move jobs [10]. Vector search rests on a 2024 Timescale benchmark of pgvector with pgvectorscale, reported as faster than Pinecone and cheaper [9], which is a vendor measuring its own extension. Durable execution is the newest: the account dates DBOS and Microsoft's pg_durable to mid-2026, using ordinary transactions and advisory locks to run crash-safe workflows without an orchestration cluster [11]. The oldest plank is the one you can lean on hardest.
What the piece does not examine is the other side of consolidation. Four workloads that had four instances now share one buffer cache and one write-ahead log, and nothing here reports what vector queries and queue polling do to transactional latency on the same server [17]. The stated ceiling comes from Stephan Schmidt, a CTO coach, whose "Just Use Postgres for Everything" was updated in December 2025 and argues that with the right indexing strategies Postgres covers Kafka, RabbitMQ, Mongo and Redis use cases up to millions of users [12]. That is a claim about indexing strategy. It is not a measurement of anybody's instance under load.
The doctrine reading is the part worth keeping. The author's own concession is the sharpest line in the piece: choosing a single-purpose tool was never the error, choosing four by default was [13]. He grants that the 2011 advice was right for 2011, when Postgres lacked what his team needed, and that the stores which followed were opened because a blog post recommended it rather than because the data demanded it [6]. Consolidation deletes three control planes [14], and that is the half you can put in a staffing plan and defend at budget time. The consistency half is the one nobody notices until after the migration, and the one that gets harder to retrofit for every year those four stores stay in production.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
The author's team ran Mongo for documents, Redis for caching, Elasticsearch for search and an unnamed vector database for AI features, removed all of them, and now uses only Postgres.
The author argues the 'most suitable solution for a particular problem' justification in practice means monitoring and maintaining four control planes.
Each store had its own backups, its own way of scaling, and something different failing at 3am; the author says this was harder to deal with than the cloud costs.
Martin Fowler coined the term polyglot persistence in November 2011, stating that 'any decent sized enterprise will have a variety of different data storage technologies for different kinds of data'.
The author says the 2011 position was reasonable then because Postgres lacked features his team required, but the motto stayed current too long and new stores were opened because a blog post recommended it, not because the data required it.
The author credits the term 'Retrieval Gap' to Tacnode's Alex Kimball in March 2026: if one decision reads from multiple stores, each read reflects a different point in time, so the decision assesses a composite state that never actually existed. The author says this subtler cost, not the bill, convinced him to migrate.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One self-published account, no measurements
The cluster contains a single dev.to opinion post. Its central outcome claim - lower bill, lower operational overhead - is stated without any figure, and every supporting technical fact (Fowler, Pigsty, Timescale's benchmark, Schmidt's manifesto, DBOS/pg_durable) is relayed secondhand with no primary artefact in the cluster. Named, dated citations lift it above pure assertion, but nothing here is independently verifiable from the supplied material.
Real tooling, one disclosed migration
Adoption evidence is concrete but shallow: one undisclosed-scale team migration, plus named, shipping ecosystem components (pgvector/pgvectorscale, pg-boss, River, DBOS, Microsoft pg_durable) that make Postgres consolidation technically available. There are no deployment counts, no named production users besides the anonymous author, and no usage metrics, so this reflects availability and a single anecdote rather than measured uptake.
Universal claim on anecdotal evidence
The framing - 'polyglot persistence was the mistake', 'Postgres was always enough', scaling 'up to millions of users' - generalises far beyond what one unquantified migration supports, and the post omits the two costs consolidation actually creates: workload contention and a single shared failure domain. The author's own Google-scale carve-out and the genuinely shipping tooling keep this from being pure hype, so the overstatement is substantial but not extreme.
Vendor-sourced framing, engagement-shaped post
The load-bearing external evidence comes from parties that sell the conclusion: Timescale benchmarking its own pgvectorscale against Pinecone, Tacnode coining the 'Retrieval Gap' the author calls decisive, and the Pigsty maintainer declaring Postgres is eating the database world. The post itself is an anonymous developer-platform piece written in a persuasive, engagement-seeking register that closes with a comment prompt. No sponsorship or affiliation is disclosed, so the incentive is inferred from the cited sources' commercial position, not from a stated conflict.
Low - single unverified narrator
Confidence is limited by cluster structure rather than internal inconsistency: one publisher, one anonymous author, zero corroboration and zero metrics. The directional reading - Postgres capability has broadened and consolidation is now a defensible default for mid-scale teams - is plausible and internally coherent, but no quantitative or comparative conclusion can be drawn from this material.
build
Three services you can delete: queue, cache and search in one Postgres1 distinct publisher
build
A RAG stack lived seven hours before a hosted embedding endpoint returned 4041 distinct publisher
build
DuckDB's vss extension removes a database from your RAG stack, then names the price1 distinct publisher
build
One Mutable vat_id Column Is An Audit Failure With A Delay Fuse1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 21, 2026