FAQs

A cluster is the running server process and its data directory, while a database is one namespace within that cluster that commonly shares the cluster with several sibling databases.

• The process model dates to PostgreSQL's early architecture and gives each session strong memory isolation.
• It simplifies crash containment, since one backend crashing does not directly corrupt another's memory.
• The trade-off is per-connection overhead, which is why pooling matters at high concurrency.

It means a long-running report query never blocks a concurrent write, a write never has to wait for readers to finish, and each transaction simply sees a consistent snapshot of the data instead of partial changes from others.

Every change is durably recorded in the WAL before the in-memory page is considered committed, which is what lets PostgreSQL replay the WAL from the last checkpoint and rebuild any lost in-memory state after a crash.

A reload re-reads postgresql.conf for settings that can change live, while a restart recycles the postmaster and every backend, which is required for settings like shared_buffers that are fixed at startup.

Not to get started, but understanding that the planner reorders and rewrites your SQL explains most "why is this slow" surprises later on.

Because types, operators, and index access methods are just rows in system catalogs, extensions can register new ones without patching the core engine's source code.

Dead tuples accumulate, tables bloat, and in the worst case the cluster approaches transaction ID wraparound, which forces PostgreSQL into a protective, disruptive cleanup mode.

Yes; 18 is the current stable major version, and 17 remains on the supported maintenance line for teams not yet ready to upgrade.

An extension can add new data types, operators, and index access methods that participate in the planner and executor exactly like built-in ones, not just add callable functions.

Yes, using separate databases or separate schemas, though each isolation boundary has different implications for backup scope and connection accounting.

Each connection is a full backend process consuming memory and competing for CPU scheduling, so hundreds of idle connections are cheap but hundreds of active ones are not.

Because its durability model, WAL-before-data-page writes plus replay on crash, has been stable and battle-tested for decades, with new features added around that core rather than replacing it.

Reload re-reads postgresql.conf for many parameters. Restart recycles all processes and is required for memory-related GUCs.

Depends on RAM and workload. Hundreds of idle connections are cheap; hundreds of active queries are not. Pool aggressively.

The data directory (PGDATA) holds heap files, WAL, and catalog. Use tablespaces only when you need separate storage paths.

No for backends. Parallel query workers are separate processes forked for a single statement.

On startup, Postgres replays WAL from the last checkpoint, then accepts connections.

Yes. Catalogs describe the cluster; most queries filter to current_database() objects.

DDL that changes user tables updates catalogs in the same transaction.

Optional comment storage tied to catalog OIDs via objoid/classoid.

pg_constraint with contype = 'f' or information_schema.table_constraints.

Slightly more view layers. For heavy introspection, pg_catalog joins are fine.

Hundreds are fine. Complexity comes from grants and migration order, not OID cost.

Schema names are per database. Same name in different DBs is unrelated.

A placeholder for a schema matching the role name; often empty.

Many installs use public. Some teams dedicate an extensions schema.

Yes for types and functions resolved for unqualified calls.

Yes for teams tracking stable releases; validate extensions and workload plans in staging.

Five years from its initial release per community policy; confirm current EOL dates on postgresql.org.

Usually no. Reindex if pg_upgrade reports invalid indexes or after collation updates.

Brief restart disconnects sessions; use pooler failover or maintenance window.

Treat version policy separately; this site documents community PostgreSQL.

Docker Postgres 18 plus pinned migrations; still use timestamptz and constraints.

Yes. Minor skew is OK; major skew hides incompatibilities.

Quarterly quick pass; full ADR review yearly.