Master Reference · extensions edition · core SQL + IDRM Top-20 extensions + spatial + network · verified against PostgreSQL 18

postgreSQL extensions cheat sheet

The full relational core — five SQL sub-languages (DDL, DQL, DML, DCL, TCL), JSON/JSONB, arrays, full-text search, CTEs & window functions, PL/pgSQL — plus a deep, authenticated tour of the 20 highest-impact PostgreSQL extensions (the IDRM ranking): performance monitoring, cryptography, fuzzy & vector search, auditing, scheduling, partitioning, time-series, testing and more. Every extension entry is checked against its official docs for PostgreSQL 18. PostGIS and pgRouting — two flagship extensions — keep their full dedicated sections below.

psql client schema (DDL) data (DML) query / read admin & perf PostGIS pgRouting destructive most common contrib ships with PostgreSQL external third-party install

Core SQL/PostGIS/pgRouting distilled from postgresql.org · postgis.net · pgrouting.org. Extension entries verified at build (2026-08-24) against each project's official docs/repo: PostgreSQL 18 contrib docs · pgvector 0.8 · pgaudit.org · github.com/citusdata/pg_cron · pgpartman/pg_partman 5.x · sraoss/pg_ivm 1.14 · reorg/pg_repack 1.5.3 · HypoPG · pgtap.org · citusdata/postgresql-hll · tigerdata.com (TimescaleDB).

Outline — jump to any section

This is a large single page. Use the index below (or your browser's find) to jump. The IDRM Top-20 extensions are the heart of this edition; the core-SQL, PostGIS and pgRouting sections are the full master reference they build on.

Core & reference

  1. Core SQL — cards 01–27 (psql, DDL/DQL/DML, JSON, FTS, PL/pgSQL)
  2. Extensions 101 — how CREATE EXTENSION works
  3. The IDRM Top-20 ranking table
  4. PostGIS — spatial (cards 28–33)
  5. pgRouting — network routing (cards 34–36)
  6. Worth memorizing · version matrix

IDRM extensions · 1–10

  1. 1pg_stat_statements query perf
  2. 2pgcrypto crypto
  3. 3pg_trgm fuzzy text
  4. 4pgvector vector search
  5. 5pgAudit auditing
  6. 6citext case-insens. text
  7. 7postgres_fdw remote PG
  8. 8pg_cron scheduled SQL
  9. 9Native UUID / uuid-ossp UUIDs
  10. 10unaccent accent-insens.

IDRM extensions · 11–20

  1. 11PostGIS geospatial
  2. 12pg_repack de-bloat
  3. 13pg_partman partitioning
  4. 14TimescaleDB time-series
  5. 15pgTAP unit testing
  6. 16HypoPG hypothetical idx
  7. 17pg_ivm incremental MV
  8. 18hll approx distinct
  9. 19hstore key-value
  10. 20file_fdw files as tables
Logical query processing order

You write a query SELECT…FROM…WHERE…ORDER BY — but the planner executes it in this sequence. This is why a WHERE clause can't see a SELECT alias, and why ORDER BY can.

1 FROM / JOIN build the row set 2 WHERE filter rows (no aliases) 3 GROUP BY collapse into groups 4 HAVING filter the groups 5 SELECT DISTINCT compute & dedupe columns 6 ORDER BY sort — aliases work here 7 LIMIT / OFFSET trim the final rows EXECUTION RUNS LEFT → RIGHT you typed: SELECT…FROM…WHERE…GROUP BY…HAVING…ORDER BY…LIMIT (written order is almost the reverse of run order — window functions run between step 4 and step 5)

Core SQL

The full relational toolkit: DDL (define), DQL (query), DML (modify), DCL (permit), TCL (transact), plus JSON/JSONB, arrays, full-text search, and PL/pgSQL.

01Connect & psql Flagsthe command line
02psql Meta-Commandsthe backslash family
03Databases & Schemastop-level containers
04Create & Alter Tablesstructure
05Constraintsdata integrity rules
06Views, Sequences & TypesDDL — derived & custom objects
07Table PartitioningDDL — split big tables
08Core Data Typeswhat to store columns as
09Query BasicsSELECT, sort, page
10FilteringWHERE clauses
11Joinscombine tables — see diagrams ↓
12CTEs & SubqueriesDQL — compose queries
13Set Ops, CASE & Grouping SetsDQL — combine & branch
14Aggregation & Groupingsummarize rows
15Window Functionsper-row aggregates, keep every row
16Modifying Datawrite operations
17Transactionsall-or-nothing changes
18Indexes & Performancemake reads fast
19Roles & Privilegeswho can do what
20Text, Date & Castingcommon functions
21Backup, Restore & CSVmove data in & out
22Monitoring & Maintenancekeep it healthy
23JSON & JSONBmodule — document data
24Arraysmodule — multi-value columns
25Full-Text Searchmodule — search documents
26Functions, PL/pgSQL & Triggersmodule — server-side logic
27Handy Extensionsmodule — CREATE EXTENSION

PostgreSQL Extensions — IDRM Top 20

PostgreSQL's superpower is that it is extensible: whole feature sets ship as installable modules. Below are the 20 highest-impact extensions by the IDRM composite rating, in rank order. contrib = bundled with PostgreSQL (in the postgresql-contrib package); external = a separate install (build from source, OS package, or your managed provider's allow-list). Verified against PostgreSQL 18 and each project's current release.

#ExtensionPrimary capabilityIDRMKind
1pg_stat_statementsQuery performance monitoring★★★★★contrib
2pgcryptoCryptography & secure values★★★★★contrib
3pg_trgmFuzzy text search (trigram)★★★★★contrib
4pgvectorVector / semantic search★★★★★external
5pgAuditDetailed database auditing★★★★★external*
6citextCase-insensitive text★★★★★contrib
7postgres_fdwRemote PostgreSQL access★★★★★contrib
8pg_cronScheduled SQL jobs★★★★★external
9Native UUID / uuid-osspUUID generation★★★★★built-in / contrib
10unaccentAccent-insensitive search★★★★contrib
11PostGISGeospatial data★★★★external
12pg_repackOnline maintenance / de-bloating★★★★external
13pg_partmanPartition management★★★★external
14TimescaleDBTime-series workloads★★★★external*
15pgTAPDatabase unit testing★★★★external
16HypoPGHypothetical indexes★★★★external
17pg_ivmIncremental materialized views★★★★external
18hllApproximate distinct counts (HyperLogLog)★★★external
19hstoreLightweight key-value data★★★contrib
20file_fdwExternal files as tables★★★contrib

IDRM = the source's composite importance rating, kept here as a star rating. external* = external but bundled/allow-listed by many distros & managed providers (pgAudit), or carrying a licensing/cloud caveat (TimescaleDB).

101Extensions 101install, list, update, drop
1pg_stat_statementscontribpreload★★★★★
2pgcryptocontrib★★★★★
3pg_trgmcontrib★★★★★
4pgvectorexternal★★★★★ · 0.8
5pgAuditexternal*preload★★★★★
6citextcontrib★★★★★
7postgres_fdwcontrib★★★★★
8pg_cronexternalpreload★★★★★
9Native UUID / uuid-osspbuilt-in+contrib★★★★★
10unaccentcontrib★★★★
11PostGISexternal★★★★ · see full section ↓
12pg_repackexternal★★★★ · 1.5.3
13pg_partmanexternal★★★★ · 5.x
14TimescaleDBexternal*preload★★★★
15pgTAPexternal★★★★ · 1.3
16HypoPGexternal★★★★
17pg_ivmexternalpreload★★★★ · 1.14
18hll (postgresql-hll)external★★★
19hstorecontrib★★★
20file_fdwcontrib★★★

PostGIS — Spatial Extension

PostGIS turns PostgreSQL into a spatial database: new geometry/geography column types, ~300 ST_ functions, and GiST indexing over a coordinate plane or sphere.

28Setup & Geometry TypesPostGIS
29SRID, geometry vs geographythe #1 source of bugs
30Constructors & Accessorsbuild & inspect geometries
31Spatial Relationshipspredicates — see diagrams ↓
32Measurement & Processingcompute & transform
33Spatial Indexing & Loadingmake it fast, get data in

pgRouting — Network Routing

pgRouting layers graph algorithms on top of PostGIS geometries — turning a table of line segments into a routable network for shortest-path, driving-distance, and multi-stop queries, all in SQL.

34Setup & TopologypgRouting
35Shortest PathpgRouting — see diagram ↓
36Network AnalysispgRouting
Reading the Placeholdersnotation used throughout

The four core joins

Same two tables, A and B — the shaded region is what each join keeps. Based on the standard SQL join-Venn convention.

INNER JOIN

Only rows where the join condition matches on both sides.

A B A ∩ B

LEFT JOIN

Every row from A, with matches from B where they exist (else NULL).

A B all of A

RIGHT JOIN

Every row from B, with matches from A where they exist (else NULL).

A B all of B

FULL OUTER JOIN

Every row from both sides; unmatched columns come back NULL.

A B A ∪ B
GROUP BY vs. window function

Both compute an aggregate per group — but GROUP BY collapses rows down to one per group, while a window function keeps every original row and attaches the aggregate alongside it.

GROUP BY col row, row, row row, row 1 summary row / group fn() OVER (PARTITION BY col) row + agg row + agg row + agg row + agg every row kept, all 4 see the same per-partition value
PostGIS spatial index: filter, then refine

Index-aware predicates (ST_Intersects, ST_Contains, ST_Covers, ST_DWithin…) run in two phases automatically — you just write the predicate.

1 · FILTER GiST R-Tree compares bounding boxes only fast · approximate · may over-include → candidate rows 2 · REFINE exact ST_ predicate runs on candidates only slower · exact · confirms real matches → final result ST_Disjoint & ST_Relate are negations — they skip the filter phase entirely full scan — avoid on big tables ⚠ not index-aware
pgRouting: from lines to a routable network

A table of disconnected line geometries becomes a weighted graph in two steps — then pgr_dijkstra and friends can search it.

1 · TOPOLOGY pgr_createTopology assigns source/target IDs from endpoints raw lines → noded graph → edges with node IDs 2 · ROUTE pgr_dijkstra / pgr_aStar walk the weighted graph by cost graph → ordered edge sequence → shortest path result cost & reverse_cost a negative value on either column blocks that direction models one-way streets ⚠ sign = direction

Reading the four common predicates

A square (table A) and a circle (table B) — the shaded/highlighted part is what each predicate tests true for.

ST_Intersects

True if A and B share any point at all — the broadest, most common test.

A B shares any point

ST_Contains / ST_Within

True if one geometry's interior fully encloses the other.

A B A contains B

ST_Touches

True only if boundaries meet — interiors never overlap.

A B shared edge only

ST_DWithin

True if a target lies inside a buffer distance d — index-aware proximity search.

A in out within distance d

Worth memorizing

WHERE ≠ HAVINGWHERE filters rows before grouping; HAVING filters the groups
DELETE ≠ TRUNCATEDELETE is row-by-row, logged, supports WHERE; TRUNCATE is instant, no WHERE
= NULL is always falseNULL has no equality — use IS [NOT] NULL
SERIAL ≠ IDENTITYSERIAL is legacy sugar; GENERATED ALWAYS AS IDENTITY is the SQL standard
VACUUM ≠ ANALYZEVACUUM reclaims dead-row space; ANALYZE refreshes planner statistics
no USE statementPostgres has no USE db — switch with \c inside psql
UNIQUE index ≠ PRIMARY KEYboth enforce uniqueness, but UNIQUE permits one NULL
autocommit is oneach statement commits immediately unless wrapped in BEGIN…COMMIT
RANK ≠ DENSE_RANKRANK leaves gaps after ties (1,2,2,4); DENSE_RANK doesn't (1,2,2,3)
window fns run after HAVINGthey can't be used in WHERE/HAVING — wrap the query and filter in an outer SELECT
-> keeps JSON, ->> gives textuse ->> when you need to compare or cast the value; -> when you'll keep drilling in
JSONB @> wants a GIN indexcontainment & JSONPath scale only with USING GIN; a plain b-tree won't help
arrays are 1-indexedarr[1] is the first element — not arr[0] as in most languages
full-text needs @@ + a tsvectorLIKE '%x%' can't rank or stem; to_tsvector + GIN + @@ does both
MATERIALIZED VIEWs go stalethey don't auto-update — REFRESH (ideally CONCURRENTLY) on a schedule
geometry ≠ geographygeometry is planar & degrees on 4326; geography is spherical & always metres
ST_MakePoint defaults to SRID 0always wrap it: ST_SetSRID(ST_MakePoint(lon,lat), 4326)
PostGIS order is (X, Y)that's (longitude, latitude) — the reverse of how people say "lat/lon"
ST_SetSRID ≠ ST_TransformSetSRID only labels the data; Transform actually reprojects the coordinates
source/target are auto-assignedpgr_createTopology fills them in — don't hand-pick these node IDs yourself
negative cost blocks a directionreverse_cost < 0 makes an edge one-way; routing functions skip it going that way
pgr_dijkstra's first arg is SQLit's a live edge query, not a table name — must return id, source, target, cost
contrib ≠ externalcontrib ships with PostgreSQL (postgresql-contrib pkg); external needs its own install & a cloud allow-list
preload ⇒ restartpg_stat_statements, pg_cron, pgaudit, pg_partman_bgw, pg_ivm, timescaledb load via shared_preload_libraries before CREATE EXTENSION
extension name ≠ project namepgvector installs as CREATE EXTENSION vector; uuid-ossp must be quoted
gen_random_uuid() is corebuilt-in since PG13 — no pgcrypto/uuid-ossp needed; PG18 adds time-ordered uuidv7()
pg_trgm gin_trgm_opsthe index that finally makes ILIKE '%x%' fast
pg_partman 5 broke the APInative-only, named params, p_type range/list — pre-5.0 tutorials no longer apply
pg_repack is a CLIyou install the extension in SQL but run the repack from the pg_repack client, not a function
HypoPG uses EXPLAIN, not ANALYZEphantom indexes shape the plan but can't be executed — ANALYZE would try to use them for real
unaccent() is STABLEcan't index it directly — wrap in an IMMUTABLE function for a functional index