The PostgreSQL extension ecosystem

Postgres lets code be installed into the running server: SQL objects, and optionally compiled C, packaged so that CREATE EXTENSION <name> makes them part of the database. Some extensions need only that; others must be loaded at startup via shared_preload_libraries (the citus install shows both steps). The mechanism is old and unremarkable. What it produced is not.

The evidence, which is a ratio rather than a number

awesome-postgres catalogs several hundred entries around PostgreSQL, and five of them are a different server — AgensGraph, Apache Cloudberry, FerretDB, Postgres-XL, YugabyteDB. Against those five sit an Extensions section of roughly 34 curated entries, which the catalog then admits is a rounding error by linking two larger indexes: a "curated list of 1000+ extensions" and Pigsty's "400+ PostgreSQL extensions" catalogue.

The nearest thing to a registry is PGXN, the PostgreSQL Extension Network — "a central distribution system for open-source PostgreSQL extension libraries," created and run by David Wheeler with donor support, comprising four parts: Manager ("an upload and distribution infrastructure for extension developers"), API ("a centralized index and API of distribution metadata"), Search, and a command-line Client. Its front page reported 495 extensions / 471 distributions / 3,172 releases when read for this ingest.

Those figures — 34, 400, 495, 1000+ — do not reconcile, and no source here claims a census. What survives the disagreement is the shape: the population of things running inside Postgres exceeds the population of alternative Postgres servers by two or three orders of magnitude.

What people build there instead of building a database

The catalog's Extensions section is a list of products that in another ecosystem would be separate systems with separate vendors:

• citus — a distributed database, coordinator and workers, shards as ordinary tables.
• TimescaleDB — a time-series database, "fully compatible with Postgres."
• PostGIS — spatial and geographic objects, plus pgRouting for network analysis on top.
• pg_search / ParadeDB / PGroonga / zomboDB — full-text search engines, one of them BM25-scored, one of them delegating to Elasticsearch-backed indexes.
• PostgresML — machine learning executed inside the database.
• pgmq — a message queue with SQS's API.
• AGE — a graph database with Cypher queries.
• cstore_fdw, and Citus's own USING columnar — a column store bolted to a row store.
• PGStrom — query execution offloaded to a GPU.
• OrioleDB — a storage engine.

That last one is the measure of how wide the seam is. The heap, the WAL interaction, the table access method — the layer beneath everything else — is reachable by an extension rather than requiring a fork. And there is a pg_paxos in the same list, "Paxos implementation for table replication": the algorithm this spoke pages from part-time-parliament and paxos-made-simple exists as an installable Postgres module, which nobody planned and the extension API permitted.

The full catalogued roster

awesome-postgres' Extensions section in full, as listed on 2026-08-20, at the catalog's word (T3) except where a page exists. Grouped by what each one adds, because the catalog's alphabetical order hides the pattern.

Registries and indexes — pgxn (the Extension Network) · Extensions listing by joelonsql ("1000+ extensions") · Pigsty extensions catalogue ("400+") · PGXN client (catalogued under Utilities)

A different database inside the database — citus (distributed SQL) · TimescaleDB (time-series) · PostGIS (spatial) + pgRouting (network analysis) · AGE (graph, Cypher) · ParadeDB (search and analytics) · PostgresML (ML and AI in-database) · pgmq (message queue, catalogued under Work Queues)

Storage and execution — OrioleDB (cloud-native storage engine combining disk and memory) · cstore_fdw (columnar store for analytics) · PGStrom (offload CPU-intensive work to GPU) · PipelineDB (continuous SQL over streams) · ZSON (transparent JSONB compression)

Search — pg_search (BM25 full-text) · PGroonga (Groonga-backed full-text) · zomboDB (Elasticsearch-backed indexes)

Replication and consensus — pglogical (logical streaming replication) · pgcat (enhanced logical replication) · pg_paxos (Paxos for table replication) · pg_shard (scale out reads and writes)

Operations — pg_cron (periodic jobs) · pg_partman (partition management) · pg_squeeze (automatic bloat cleanup with minimal locking) · pg_stat_monitor (query performance monitoring) · HypoPG (paged: hypopg) · StatsMgr (catalogued under Monitoring)

Audit, compliance and testing — PGAudit (session and object audit logging) · pgMemento (trigger-based audit trail) · cyanaudit (column-level DML logging) · PostgreSQL Anonymizer (mask PII using security labels) · PG_Themis (Themis crypto binding) · pgTAP (database testing framework) · plpgsql_check (PL/pgSQL source checking)

And one joke that proves the point — pg_barcode, an SVG QR-code and Datamatrix generator, running inside the database server.

Three entries here are worth reading at the primary before anything else in the section. pg_paxos is the algorithm this spoke pages from part-time-parliament, shipped as an installable module. OrioleDB is a storage engine delivered as an extension, which is the strongest single test of how deep the seam goes — and the natural counterpart to yugabytedb, which forked precisely because it needed to replace the layer OrioleDB is trying to reach from outside. pg_squeeze attacks table bloat with minimal locking, which is the MVCC cost this spoke flagged as pgmq's unmeasured risk and pgbench's reason for unrepeatable results.

Also catalogued and unfiled elsewhere: the one-entry Platforms section, Atlas4D ("open-source 4D spatiotemporal platform combining PostGIS/TimescaleDB"), which is two of the extensions above composed into a product.

The argument this settles, and the cost it carries

citus made the case from one vendor's side: it is a distributed database that refused to leave Postgres because the extension seam was wide enough, and its reward is that PostGIS, JSONB and partitioning keep working on sharded tables. The catalog is that argument at population scale. When this ecosystem wants a new capability, it overwhelmingly writes an extension or a sidecar; forking is rare enough to be countable on one hand.

Two costs are visible in the sources rather than argued in them.

Version coupling. A C extension is compiled against a server version. citus's page records three release branches maintained in parallel to track supported Postgres versions — the tax for living inside someone else's release cadence, paid by every extension author and passed to every operator planning a major upgrade.

Permission. Loading code into the server is a privileged act, which is exactly what a managed platform will not grant. pgmq ships a second, SQL-only installation path for this reason, in its own words "if you are running someplace that does not natively support the PGMQ Extension." So the open ecosystem of a thousand extensions meets a per-provider allowlist at the moment of deployment, and the catalog's eighteen PaaS entries each publish a different one. (That framing is my reading; the sources state the workaround, not the analysis.)

Related

postgresql · citus · pgmq · hypopg · yugabytedb · pg-stat-statements · awesome-postgres · paxos · part-time-parliament · multiversion-concurrency-control · postgres-managed-services · operational-databases · analytical-databases