intermediate

Extensions

Adopt extensions such as pg_trgm, PostGIS, uuid-ossp, or pgvector with deployment and portability costs in mind.

Extensions add capabilities via `CREATE EXTENSION` without forking PostgreSQL. Popular ones:

| Extension | Purpose | |-----------|---------| | pg_trgm | Trigram similarity, fuzzy LIKE | | PostGIS | Geospatial types and queries | | uuid-ossp / pgcrypto | UUID and crypto helpers | | pgvector | Vector similarity for RAG | | citext | Case-insensitive text |

					CREATE EXTENSION IF NOT EXISTS pg_trgm;

CREATE INDEX idx_users_name_trgm ON users USING GIN (name gin_trgm_ops);

SELECT name FROM users
WHERE name % 'jon'  -- similarity operator
ORDER BY similarity(name, 'jon') DESC
LIMIT 10;
				

Extensions affect portability, backup/restore, managed-cloud allowlists, and upgrade paths. Pin versions in migrations and document operational ownership.

On interviews: name an extension tied to a real feature (geo, fuzzy search, vectors), and mention deployment constraints on RDS/Cloud SQL.

Common pitfalls: enabling extensions in prod without staging validation; assuming every host ships PostGIS; mixing extension types with app-level duplicates; no rollback plan when an extension blocks upgrades.

The trade-off is faster feature delivery inside Postgres versus dependency on DBA tooling, cloud support, and migration complexity.

Checklist:

  • Map extension to a concrete query need.
  • Verify availability on target hosting.
  • Version-pin in migration scripts.
  • Document restore and upgrade implications.