Postgres as the Universal Substrate
The 'PostgreSQL for Everything' post sparked a thread where the most common response was essentially 'yes, correct, finally.' Developers are using Postgres as a queue, a cache, a job runner, a search index, and now via pg_gpt2 and similar extensions, even as an inference layer. The older the commenter, the more they seem to agree with the premise.
The through-line here connects to several other threads today. PgDog (YC P25) is hiring specifically around Postgres scaling, and Supabase is hiring for Multigres. The ecosystem is betting hard that Postgres can be the single stateful layer for most applications rather than a patchwork of Redis, Kafka, Elasticsearch, and five other systems.
The pushback is practical: Postgres-for-everything works great at startup scale and breaks down when you hit genuine throughput walls. But for most founders, those are good problems to have, and deferring the distributed systems complexity until you actually need it is the right call.
So what?
If you're starting a new product or rearchitecting an existing one, defaulting to Postgres for queuing, caching, and search before adding Redis or Elasticsearch is not just acceptable, it's likely the faster path to shipping. Resist the urge to add infrastructure complexity before you have the load that justifies it.