CHECKPOINT Statement

The CHECKPOINT statement synchronizes data in the write-ahead log (WAL) to the database data file.

Examples

Synchronize data in the default database:

CHECKPOINT;

Synchronize data in the specified database:

CHECKPOINT file_db;

Synchronize data and prevent new transactions from starting:

FORCE CHECKPOINT;

In earlier DuckDB versions, FORCE CHECKPOINT aborted any in-progress transactions. From v1.4, it waits until it can grab the checkpoint lock.

Checkpointing In-Memory Tables

Starting with v1.4.0, in-memory tables support checkpointing. This has two key benefits:

In-memory tables also support compression. This is disabled by default – you can turn it on using:
```
ATTACH ':memory:' AS memory_compressed (COMPRESS);
USE memory_compressed;
```
Checkpointing triggers vacuuming deleted rows, allowing space to be reclaimed after deletes/truncation.

Syntax

Checkpoint operations happen automatically based on the WAL size (see Configuration). This statement is for manual checkpoint actions.

Behavior

The default CHECKPOINT command will fail if there are any running transactions. Including FORCE will wait until it can grab the checkpoint lock and then execute the checkpoint operation. In DuckDB versions before v1.4, FORCE CHECKPOINT instead aborted any in-progress transactions.

Also see the related PRAGMA option for further behavior modification.

Reclaiming Space

When performing a checkpoint (automatic or otherwise), the space occupied by deleted rows is partially reclaimed. Note that this does not remove all deleted rows, but rather merges row groups that have a significant amount of deletes together. In the current implementation this requires ~25% of rows to be deleted in adjacent row groups.

Since v1.4.0, checkpointing also applies to in-memory databases (see Checkpointing In-Memory Tables), where it likewise vacuums deleted rows and reclaims space.

Warning The VACUUM statement does not trigger vacuuming deletes and hence does not reclaim space.