Include external PostgreSQL tablespaces in the cluster dependency inventory

Keep external tablespace paths with the database cluster recovery inventory.

Source facts

PostgreSQL 17 tablespaces may live outside the main data directory, but they remain integral parts of the cluster. They depend on metadata in that directory and cannot be attached to another cluster or backed up as autonomous database files. Losing a tablespace can make the cluster unreadable or unable to start. PostgreSQL tracks nondefault tablespace locations through links in pg_tblspc, and the documented location for a new tablespace must be an existing empty directory owned by its operating-system user.

Source: PostgreSQL 17 — Tablespaces.

Applicability

This applies to PostgreSQL 17 storage layout and recovery inventory. It addresses external tablespace dependencies, rather than endorsing manual filesystem-link changes or independent tablespace recovery.

DSE recommendation

DSE recommends keeping a tablespace map with the cluster’s storage and backup records. Include its location, storage owner, intended objects, mount dependency, and recovery destination. Review that map whenever data is moved to a different tier or a mount is retired. Ask the recovery operator to identify every required path before startup. Avoid treating a small main data directory as evidence that most of the database lives safely somewhere else without a corresponding dependency record.

Verification

Compare the catalog’s tablespace list with the operating-system paths and backup inventory in a read-only review. Rehearse recovery of the complete cluster with those paths present. Confirm intended objects can be read and document any deliberately remapped locations before accepting the recovered service.

Official reference

PostgreSQL 17 — Tablespaces. Reviewed October 15, 2026.