It's 2026, Just Use Postgres

Postgres as Default vs. “Postgres for Everything”

• Many agree Postgres is an excellent default OLTP database: powerful, boring, free, well-documented, and good enough to get to “medium scale” in most domains.
• Several argue the right heuristic is “start with Postgres and move when you have concrete problems,” not “never use anything else.”
• Others push back that the article overcorrects from the old NoSQL hype and now encourages shoehorning Postgres into workloads where specialized tools are clearly better.

Redis, Caching, and Data Structures

• Strong defense of Redis: its value is specialized in‑memory data structures and algorithmic complexity; when used “well,” Postgres cannot fully replace it.
• Counterpoint: most teams use Redis only as a cache, often poorly; in those cases Postgres (or even in‑app/memcached) may be simpler.
• Debate over using UNLOGGED tables as a cache: some like the idea; others note they’re still on disk and only skip WAL, so claims about “in‑memory” are misleading.

SQLite vs Postgres

• SQLite praised for simplicity, dev/test convenience, easy backups, and being ideal for small or single‑user deployments.
• Critics note SQLite’s multi-writer limitations, locking, and lack of some Postgres features; for many, “simple Postgres” ends up less painful than wrestling with SQLite’s constraints.
• Some advocate a progression: SQLite until you can’t, then Postgres until you can’t.

HA, Replication, and Operations

• Several complain Postgres lacks built‑in, easy high availability and automated failover; production HA typically requires extra tooling (Patroni, operator stacks, cloud services).
• Discussion that Postgres replication is not “CP” under network partitions; attempts to layer consensus (Yugabyte, Cockroach, etc.) come with tradeoffs.
• Others contrast MySQL/MariaDB ecosystems as operationally simpler in some HA/upgrade scenarios.

Performance, Storage, and Extensions

• Some report Postgres using significantly more disk per row than MySQL/MariaDB, leading to cost concerns, though compression at the filesystem level (e.g., ZFS) can help.
• Extensions (Timescale, pgvector, columnar plugins) are seen as powerful but operationally fussy; desires for native vector support, temporal tables, and better HA.

Search, Analytics, and Specialized Systems

• Elasticsearch, Pinecone, ClickHouse, DuckDB, and others are cited where Postgres is workable but not ideal for heavy analytics, aggregations, or advanced vector/hybrid search.
• Common pattern proposed: use Postgres early; add specialized OLAP/search systems later when real data and scale justify the cost.

Workload Mixing and “More Postgres”

• Important nuance: emulating multiple database paradigms inside a single Postgres instance can cause contention and tuning conflicts.
• Suggested strategy: split into multiple Postgres instances, each tuned for a workload, to keep a unified toolchain while avoiding cross-workload interference.

Other Databases & Legacy Choices

• MSSQL and Oracle are defended mainly for existing ecosystems, tooling, and PL/SQL/TSql investments; few would choose Oracle greenfield due to cost.
• Some are moving from Postgres back to MySQL/SQLite to avoid VACUUM and operational “footguns,” while others argue Postgres’s richer indexing and features are worth it.

Meta: AI-Generated Article Concerns

• Many commenters believe the blog post itself is heavily LLM‑generated, citing its tone, structure, and marketing style.
• There’s debate over whether such content should be flagged or removed from HN, and frustration about “AI slop” diluting genuine technical writing, even when the core message (Postgres as a solid default) resonates.