In PostgreSQL, the UNLOGGED keyword can be placed before TABLE or MATERIALIZED VIEW in a CREATE statement. Pages modified in an UNLOGGED relation are not written to the write ahead log (WAL). Skipping WAL greatly reduces disk I/O and can improve insert and update throughput, especially for bulk-load or transient data.However, because WAL is what allows PostgreSQL to recover after a crash and to stream changes to replicas, UNLOGGED objects come with two critical caveats:1. Crash survival - After an unexpected server crash or immediate shutdown, the contents of every UNLOGGED relation are automatically truncated to zero rows.2. Replication - UNLOGGED relations are not shipped to physical or logical standbys, so they only exist on the primary server.UNLOGGED is different from TEMPORARY. A TEMPORARY table is scoped to a session, whereas an UNLOGGED table is permanent in the catalog but simply lacks WAL logging. An UNLOGGED table can be converted back to a normal (LOGGED) table with ALTER TABLE SET LOGGED, after which existing data is rewritten and future changes are WAL-logged.Performance benefits are workload-dependent. Write-heavy tables that do not need durability or replication (such as staging, ETL, or caching layers) often see double-digit percentage gains. Read performance is largely unchanged because data still resides on disk buffers.
TEMPORARY TABLE, CREATE TABLE, ALTER TABLE, WRITE AHEAD LOG, LOGGED, CHECKPOINT, CLUSTER
PostgreSQL 9.1
No. After a crash or immediate shutdown, PostgreSQL automatically truncates the table because no WAL was written.
No. Because changes are not in WAL, physical and logical replicas never see UNLOGGED data.
No. TEMPORARY tables are session-scoped but crash-safe, whereas UNLOGGED tables are permanent catalog objects that lose data on crash.
Issue ALTER TABLE table_name SET UNLOGGED; PostgreSQL rewrites the table so future modifications bypass WAL.