The mechanics first, because they’re brief: when default_tablespace is anything but an empty string, it supplies an implicit TABLESPACE clause for every CREATE TABLE and CREATE INDEX that lacks an explicit one — including the index behind a UNIQUE or PRIMARY KEY constraint. The default is the empty string, which means “use the database’s own tablespace,” and the context is user. To have an opinion about this parameter you need an opinion about tablespaces, and mine, in 2026, is: mostly don’t. We’ll get there. Quirks first.
Three behaviors that will surprise you
A nonexistent name fails silently. If the value names a tablespace that doesn’t exist, PostgreSQL doesn’t error — it quietly uses the database’s default instead. Fat-finger fastpace for fastspace in a role’s settings and every table that role creates lands in pg_default, no warning, no log line, discovered months later when someone asks why the SSD tablespace is empty. (A tablespace that exists but where you lack CREATE privilege does error, which is the behavior you’d have expected from both.)
It doesn’t apply to the things you might assume. Temporary tables consult temp_tablespaces instead — a separate parameter with its own post far down the alphabet. CREATE DATABASE ignores it too; a new database inherits its tablespace from the template it’s cloned from.
Partitioned tables make it sticky. If default_tablespace is non-empty when you create a partitioned table, that value is recorded as the partitioned table’s tablespace — and from then on it’s the default for every future partition, even after default_tablespace itself changes. A setting you flipped on briefly in one session can thus haunt a partition set for years, handing out a tablespace nobody remembers choosing. If you work with partitioned tables and tablespaces together, check pg_class.reltablespace on the parent before assuming you know where new partitions will go.
The opinion
Tablespaces are a feature from the spinning-disk era, and the docs still carry the era’s justifications: put the hot index on the expensive fast disk, escape to another volume when the first one fills. Both were real in 2005. Today the fast disk is the only disk, cloud block storage makes “another volume” an API call that resizes the one you have, and on managed services tablespaces are either unsupported or land on the same underlying device, which makes them a labeling exercise. Meanwhile the costs stayed: every tablespace is a symlink in pg_tblspc pointing at an absolute path that must exist — with the same path — on every replica; backup tools have to map and remap them on restore; losing a tablespace can render the whole cluster unstartable, since its metadata lives in the main data directory; and allow_in_place_tablespaces already toured how much tooling quietly assumes the symlink layout. The legitimate survivors are genuine storage tiering on hardware you own — bulk cold partitions on cheap disks, hot data on NVMe — and temp-spill isolation, which is temp_tablespaces’ department anyway.
If you have one of those survivors, then like default_table_access_method, this parameter is the deployment mechanism for a deliberate decision: set it per-role or per-database so that the archive-loading role’s tables land on the archive tablespace without fifty DDL files each remembering a TABLESPACE clause, and mind the partitioned-table stickiness while you do. If you don’t have one of those survivors — and most installations in 2026 don’t — leave it empty, leave pg_default as the only tablespace in the cluster, and enjoy the durable pleasure of backups and replicas that never have to think about symlinks.