What’s Slowing Down Your Postgres Queries (And How to Speed Them Up)

Got slow PostgreSQL queries? It’s often more than just SQL, issues with the planner, memory settings, or state states may be the real culprits. Here’s how to start troubleshooting:

• Get real performance data: Use EXPLAIN (ANALYZE,BUFFERS,VERBOSE), not just EXPLAIN, to see actual execution time, I/O, and whether Postgres picked the right plan.
• Raise work_mem: Disk spills from sorts or hashes will slow your queries. Look for Disk: in EXPLAIN ANALYZE.
• Monitor temp files: Spills may still happen even with tuning. Use pg_stat_database.temp_bytes for aggregate spill volume over time, or log_temp_files to pinpoint which queries spill and file sizes.
• Watch for stale stats: High n_dead_tup or an old last_analyze in pg_stat_all_tables means it’s time to ANALYZE or tune autovacuum to update stats faster.
• Audit index usage: Use pg_stat_user_indexes to find rarely used, space-heavy indexes (idx_scan low).

SELECT schemaname, relname, indexrelname, idx_scan
FROM pg_stat_user_indexes
ORDER BY idx_scan ASC;

Check bloat with pgstattuple (dead tuples, free space, live %):

SELECT * FROM pgstattuple('<schemaname>.<myindex>');

Reindex if bloat is high (mind the leftmost prefix rule). Validate usefulness with EXPLAIN and query frequency via pg_stat_statements.

• Tune parallel plans: If EXPLAIN (ANALYZE) shows no Gather or Parallel nodes, the planner likely skipped parallelism due to cost, data size, or query structure.

PostgreSQL can deliver excellent performance when properly configured and memory is used efficiently.

🔍 What We’re Watching in the Database Ecosystem

OpenAI: Scaling PostgreSQL to the Next Level At PGConf.dev 2025, Bohan Zhang shared how they scale Postgres with a single writer and 40+ read replicas but still face write bottlenecks, replication lag, and vacuuming issues. This is a reminder that scaling Postgres is challenging, even for top teams.

To SQL or Not To SQL: That Is Not the Question Hermann Baer challenges the traditional SQL vs. NoSQL debate, emphasizing that the focus should be on selecting the appropriate data model for specific application needs. He highlights how modern databases often blend relational and non-relational features, such as JSON support in SQL systems, to offer greater flexibility.

Introducing Claude 4 Anthropic’s Claude 4 release, featuring Opus and Sonnet, significantly advances coding, reasoning, and tool use. Opus outperformed GPT-4 on SWE-bench. GitHub is adopting Claude Sonnet 4 to power its new Copilot coding agent, citing strong performance in agentic tasks.

In Case You Missed It

📖 New on the Blog: In his latest post, Bianchi breaks down how slow database queries don’t just hurt performance, they cost you users, revenue, and market share. He explains why conventional workarounds like read replicas and manual caching often backfire, and shows how a new approach to database performance with Readyset gives users a competitive advantage.