Five Postgres extensions we would install again, ranked

Rankings usually compare rivals. These five cooperate; the ranking is how confidently we would install each on a database we get paged for.

1. pg_stat_statements. Ships with Postgres, off by default, and it is the single highest value-per-config-line in the ecosystem's history. Every "why is the database slow" investigation starts here or starts wrong. If a managed provider doesn't enable it, that fact belongs in your provider ranking.

2. PostGIS. The reference argument for extensions as a concept: a full geospatial engine that has outlived several companies founded to replace it. If your data has coordinates, you have no decision to make.

3. pgvector. Embeddings next to your rows, one join away, no second database to operate. Not the fastest vector search at large scale, and for the majority of teams that scale ceiling is theoretical while the ops savings are monthly.

4. pg_partman. Partition management without the hand-rolled cron script that has a bug you will find during an incident. Earns its rank the month your time-series table hits its first billion rows.

5. pg_cron. Scheduling inside the database. Fifth because the failure mode is social, not technical: jobs hidden in the database are jobs nobody remembers exist. Install it with a rule about where jobs get documented.

The skip: any extension your managed provider has to approve one ticket at a time. The list above is supported by RDS, Cloud SQL and the independents alike, which is exactly why it is the shortlist. Scores in the chart are our confidence, illustrative, as of March 2026.