Extensions
pgcli supports installing and managing PostgreSQL extensions from the Pigsty DEB repository.
How It Works
Extensions are baked into a derived container image:
pg extension installbuilds a new image (based on the current image + Pigsty repo + extension packages)- Stops and removes the old container
- Recreates the container from the new image (host data volumes are preserved)
- Updates
image_tagin the config file
Benefits of this approach:
- Extensions survive container rebuilds (baked into the image layer)
pg startdoes not need to runapt-get installon every boot- Extension files are persistent and decoupled from the container lifecycle
Commands
Install Extensions
Restart confirmation: Extensions requiring shared_preload_libraries (e.g., pg_stat_statements, pg_cron) need a PostgreSQL restart. By default, you will be prompted for confirmation:
If you decline the restart, you can apply the changes later:
List Installed Extensions
Example output:
- managed: tracked by pgcli (recorded in config, included in image)
- unmanaged: manually installed extensions (not tracked in config)
Remove Extensions
Workflow:
DROP EXTENSION IF EXISTS pgmq- Update config and
shared_preload_libraries - No image rebuild — the
-extimage is shared across instances and packages are never uninstalled
Restart confirmation: If removing extensions that require shared_preload_libraries (e.g., pg_stat_statements, pg_cron), you will be prompted for confirmation before restarting:
If you decline the restart, you can apply the changes later:
View Available Extensions
Lists all 440 known extensions:
- 45 builtin (contrib, already in the base image — no image build needed)
- 395 Pigsty catalog (from Pigsty DEB repo, requires image build)
Extension Catalog
See Extension Catalog for the complete list of 45 built-in extensions (no install needed).
See Popular Extensions for usage examples of the most commonly used extensions.
Extensions Outside the Catalog
Only extensions in the catalog (builtin + Pigsty) can be installed via pg extension install. Unknown extension names are rejected before the build starts:
Full catalog: https://pigsty.cc/ext/list/
Configuration
After installing extensions, the config is updated:
The image_tag points to the derived image containing all installed extensions.
Shared Preload Libraries
Extensions requiring shared_preload_libraries are automatically configured in postgresql.conf:
Extensions that must be loaded first (e.g., citus, timescaledb) are
automatically placed at position 0 regardless of install order — PostgreSQL
fatals if they appear anywhere else.
This is a postmaster-level parameter; PostgreSQL must be restarted after changes.
Troubleshooting
Extension Install Failure
Cause: Extension name is not in the builtin contrib list or Pigsty catalog.
Resolution:
- Verify the extension name:
pg extension available - Check the Pigsty catalog: https://pigsty.cc/ext/list/
- Note the exact SQL extension name (e.g.,
vectornotpgvector)
CREATE EXTENSION Failure
The extension is installed but not tracked in config. You can safely ignore this, or manually add it to the config:
Shared Preload Library Conflict
If shared_preload_libraries was manually edited in postgresql.conf, pgcli’s sentinel block will overwrite it.
Resolution: Remove the manual configuration and let pgcli manage it.
Notes
- Extension count: 45 builtin (contrib) + 395 Pigsty catalog = 440 total known extensions
- Image size: Each extension adds 10-50MB to the image, but Pigsty packages are optimized
- Build time: First extension install takes 1-3 minutes (download + build); subsequent installs are faster (cache hits)
- Replica behavior: Replicas can install extensions, but
CREATE EXTENSIONwill be rejected (read-only). Install on the primary; replicas sync via physical replication - Extension upgrades:
ALTER EXTENSION ... UPDATE TO ...is not yet supported; run manually viapg exec
Built-in PostgreSQL extensions available in the base image
Usage examples for the most commonly used PostgreSQL extensions