Postgres isn't slow, your storage is
Many engineers attribute PostgreSQL slowness to the database itself, but commenters argue that cloud-era choices like network-attached storage (e.g., EBS) and suboptimal schemas or queries are often the real bottlenecks. They contrast local NVMe and carefully tuned indexes with managed, replicated block storage, highlighting trade-offs between latency, operational simplicity, reliability, and cost. The thread also touches on broader themes: how cloud abstractions obscure hardware realities, when specialized databases or even SQLite on fast local disks can outperform heavyweight setups, and growing frustration with AI-generated technical content.
Perceived AI-Generated “Slop” Content
- Several commenters feel blog titles and prose increasingly look LLM-generated, which makes them less inclined to read, even when the topic is relevant.
- Others push back, noting the “X isn’t slow, Y is” pattern long predates LLMs.
- There is recurring frustration about constant accusations of AI authorship; some find the meta-complaints more annoying than possible AI content.
- Ideas floated: automated AI-detector labels on HN links, or voluntary “AI-assisted” labels, so readers can filter if they want.
What Actually Makes Postgres “Slow”?
- One camp: storage is often the bottleneck, especially cloud network-attached volumes vs local NVMe; real-world latency drops (e.g., 1.0ms → 0.1ms) are reported after moving to local NVMe.
- Another camp: schema design and queries are more frequently the real problem than storage—bad indexing, “portable” schemas, and lack of database-specific tuning.
- Some highlight specific Postgres techniques: index-only scans / covering indexes, index layout (“column Tetris”), index bloat management, and realistic statistics in production.
- Consensus: both storage and schema/query design matter; neither alone can salvage an extreme weakness in the other.
Cloud Storage vs Local Disks
- Many criticize cloud block storage (e.g., EBS) as slow and overpriced compared to local NVMe, arguing that cloud hides how fast modern hardware really is.
- Defenders emphasize operational benefits: easy replication, failover, resizing, snapshots, and not having to manage RAID, spares, and 3 a.m. emergencies.
- There is detailed debate over cost: some say cloud is “insanely expensive” versus rented bare metal; others note rising on-prem hardware prices and cloud’s labor/time savings.
- Several point out that app-level replication on local NVMe can outperform networked storage but requires serious engineering and operational discipline.
Alternatives, Specialization, and Hardware Acceleration
- SQLite on local NVMe is praised for ultra-low latency in single-node scenarios (web apps, game servers), with concerns mostly around durability and backups.
- DuckDB + NVMe is seen as excellent for analytics but limited by concurrency constraints.
- Some speculate about LLM-generated, highly specialized databases; most replies stress reliability, ecosystem, and the immense complexity of building a DBMS.
- There is interest in hardware acceleration (FPGAs, SmartSSDs, GPUs) for joins and scans, though commenters note commercial and operational barriers.