Postgres es suficiente para la mayoría de proyectos software y reduce la complejidad operativa de mantener múltiples bases de datos especializadas. La premisa, originada en un gist y una discusión en Hacker News, sostiene que la mayoría de equipos adoptan prematuramente arquitecturas con numerosos microservicios y almacenes de datos —Redis para caché, Elasticsearch para búsqueda, MongoDB para documentos, Kafka para eventos, Snowflake para analítica—, incurriendo en sobrecarga operativa, mayores costes, monitorización compleja y depuración más lenta.
El argumento se apoya en datos: aproximadamente el 0,3% de los proyectos software alcanza una escala que justifique arquitecturas distribuidas avanzadas. Empresas como Notion, Netflix o Instagram confían en tecnologías consideradas "aburridas" para servir a millones de usuarios. Antes de añadir un nuevo sistema, conviene explorar alternativas nativas en Postgres: tablas UNLOGGED y vistas materializadas para caché; SKIP LOCKED, pgmq y pgflow para colas de trabajos; tsvector, pg_trgm y ParadeDB para búsqueda de texto completo; JSONB y FerretDB para documentos flexibles; pgvector y pgvectorscale para búsqueda vectorial e IA; TimescaleDB y pg_partman para series temporales; pg_analytics e integración con DuckDB para analítica; Apache AGE y CTEs recursivos para grafos; y PostGIS para datos geoespaciales.
El texto no plantea dogmatismo: cuando Postgres alcanza sus límites, documentados y probados, puede justificarse incorporar infraestructura especializada. Cada sistema adicional implica años de mantenimiento, monitorización y depuración, por lo que añadir uno solo debería compensar ese coste a largo plazo.