Extensions
44 PostgreSQL extensions are compiled into the engine — pgvector, pg_trgm, hstore, pgcrypto, pgaudit and most of the RDS for PostgreSQL 18 list. Turn one on with CREATE EXTENSION.
Extensions are compiled into the engine. Your project opts in with CREATE EXTENSION, exactly as on PostgreSQL; there is nothing to install and no shared library to load. The set follows the one RDS for PostgreSQL 18 publishes, minus what a single-process embedded engine cannot host (see the end of this page).
CREATE EXTENSION vector;
CREATE EXTENSION pg_trgm;Each extension's own regression suite is run against a reference PostgreSQL 18.6 with the same extension built in, and the output is byte-identical except where this page says otherwise.
What is built in
| Area | Extensions |
|---|---|
| Text search and matching | pg_trgm 1.6 · pg_bigm 1.2 · pg_similarity 1.0 · fuzzystrmatch 1.2 · unaccent 1.1 · citext 1.8 · prefix 1.2 · dict_int 1.0 · dict_xsyn 1.0 |
| Vectors and data types | vector (pgvector) 0.8.7 · hstore 1.8 · ltree 1.3 · cube 1.5 · earthdistance 1.2 · seg 1.4 · isn 1.3 · ip4r 2.4 · intarray 1.5 · hll 2.21 · roaringbitmap 1.3 · uuid-ossp 1.1 · lo 1.2 |
| Indexing and planning | btree_gin 1.3 · btree_gist 1.8 · bloom 1.0 · hypopg 1.4.3 · tsm_system_rows 1.0 · tsm_system_time 1.0 · amcheck 1.5 · pageinspect 1.13 · pg_hint_plan 1.8.1 · auto_explain |
| Utilities | pgcrypto 1.4 · tablefunc 1.0 · orafce 4.17 · pg_partman 5.5 · pgtap 1.3.5 · tcn 1.0 · autoinc 1.0 · insert_username 1.0 · moddatetime 1.0 · refint 1.0 |
| Audit and extension hosting | pgaudit 18.0 · pg_tle 1.5.3 |
How to turn one on
Most: CREATE EXTENSION name; once per database. It is a normal DDL statement, so it goes in a migration like any other schema change.
Two are modules, not extensions — they have no CREATE EXTENSION; load them into the session that needs them:
LOAD 'pg_hint_plan';
LOAD 'auto_explain';A LOAD lasts for the session. With env.db, read Sessions first — the default is a fresh session per call. pg_hint_plan also has a CREATE EXTENSION pg_hint_plan for its hint_plan.hints table; the hints in comments work with LOAD alone.
Known differences
Every extension installs and does its job. A few have a corner of their own test suite that asks for something an embedded single-process engine does not have:
| Extension | Does not work | Works |
|---|---|---|
amcheck | verify_heapam — it reads 8 kB heap pages, and table rows are not stored as heap pages here | bt_index_check, bt_index_parent_check |
pageinspect | the heap-page functions (heap_page_items, get_raw_page on a table) | every index-page function — bt_page_items, gin_*, brin_*, page_header, fsm_page_contents |
pg_hint_plan | the debug trace's statement numbering differs in places | the hints apply; the plans are PostgreSQL's |
pg_partman | its background worker (pg_partman_bgw) — there is no second process | everything else; call run_maintenance() yourself, for example from runlot cron |
pg_tle | ALTER SYSTEM (there is no postgresql.auto.conf) and the passcheck / clientauth hooks that run in a background worker | installing and running TLE extensions, base types, operators, the feature registry |
pgaudit | auditing CREATE/ALTER/DROP DATABASE — one database per project | everything else; set pgaudit.log and the audit lines appear in your project's log |
pgvector: when HNSW indexes are repaired
After deletes, an HNSW index is repaired by VACUUM, and that repair is expensive — around 46 seconds for 100,000 rows with 1 % deleted. So the hourly maintenance sweep leaves tables with an HNSW index alone, and they are repaired when your project goes idle and parks, where the budget is 10 minutes per table. If your project never goes idle, those tables keep their deleted rows until it does; the index still answers correctly, it just does not shrink. Where deletes are frequent and the project is never idle, prefer IVFFlat, whose repair costs the same as a B-tree.
env.vectors is unchanged by this: it keeps its own store and exact search, as documented on its page. pgvector is available to your own SQL.
What is not included, and why
The engine is one process per project, with one database. Anything that needs a second process is out by design, not pending: extensions with a real background worker loop (pg_cron, TimescaleDB), logical-decoding output plugins (pglogical, wal2json), extensions carrying their own libpq, PL/Perl and PL/Python, libxml-based extensions, and WAL or pg_control inspection. PostGIS is not on the list today.
Loading your own shared library is not possible either, and will not be: the per-project process is the isolation boundary.