default_tablespace

Definition PG 18 manual

This variable specifies the default tablespace in which to create objects (tables and indexes) when a CREATE command does not explicitly specify a tablespace.

The value is either the name of a tablespace, or an empty string to specify using the default tablespace of the current database. If the value does not match the name of any existing tablespace, PostgreSQL will automatically use the default tablespace of the current database. If a nondefault tablespace is specified, the user must have CREATE privilege for it, or creation attempts will fail.

This variable is not used for temporary tables; for them, temp_tablespaces is consulted instead.

This variable is also not used when creating databases. By default, a new database inherits its tablespace setting from the template database it is copied from.

If this parameter is set to a value other than the empty string when a partitioned table is created, the partitioned table's tablespace will be set to that value, which will be used as the default tablespace for partitions created in the future, even if default_tablespace has changed since then.

For more information on tablespaces, see Section 22.6.

How it works

default_tablespace sets the default tablespace to create tables and indexes in. An empty string means use the database's default tablespace. It selects the destination for new persistent tables and indexes, not temporary objects or CREATE DATABASE; an invalid configured name falls back to the database default in some contexts.

default_tablespace is a USER-context setting. An authorized role can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.

It supplies a default only when SQL omits an explicit choice, so schema migrations, object-level options, privileges, and later ALTER operations can override or outlive it.

Operational considerations

Changing default_tablespace in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.

Expecting a changed default to rewrite existing objects or override explicit DDL clauses.

Ignoring tablespace privileges, installed access methods or compression support, and restore portability.

Changing default_tablespace globally without a rollback plan and a client or operational compatibility test.

Workload guidance

OLAP: Use default_tablespace deliberately for bulk objects and spill-heavy jobs, checking I/O placement, compression support, and operational tooling before adoption.

OLTP: Keep default_tablespace aligned with schema-management policy and make important storage choices explicit in migrations. Benchmark any physical-layout change with production-shaped writes.

SMALL: Prefer the upstream default for default_tablespace unless the node has a verified alternate storage path or restore requirement; simplicity reduces recovery surprises.