Skip to content

CONCEPT Cited by 1 source

Postgres TRUNCATE CASCADE / RESTART IDENTITY

Postgres's TRUNCATE TABLE is a richer DDL statement than MySQL's. It supports three capabilities MySQL does not: CASCADE, RESTART IDENTITY / CONTINUE IDENTITY, and transaction safety (rollback).

Postgres's TRUNCATE TABLE statement for truncating a table supports the CASCADE keyword. It also supports features like RESTART IDENTITY, CONTINUE IDENTITY, transaction-safe, and so on. RESTART IDENTITY tells Postgres to reset all identity columns when truncating a table automatically, and transaction-safe means that the truncation will be safely rolled back if the surrounding transaction doesn't commit.

In contrast, MySQL's TRUNCATE TABLE feature supports neither CASCADE nor transaction safe, which means that data can't be rolled back once it's deleted.

sources/2026-04-21-planetscale-migrating-from-postgres-to-mysql

Feature matrix

Capability Postgres MySQL
CASCADE — recursively truncate FK-dependent tables Yes No
RESTART IDENTITY — reset auto-increment sequences Yes No (implicit; AUTO_INCREMENT resets to 1 as a side-effect)
CONTINUE IDENTITY — preserve auto-increment value Yes n/a
Transaction-safe (can be rolled back) Yes No — TRUNCATE auto-commits

Why transaction safety matters

Postgres:

BEGIN;
TRUNCATE TABLE audit_log;
-- verify downstream work
ROLLBACK;  -- audit_log rows are restored

MySQL has no analogue — TRUNCATE TABLE audit_log in an open transaction auto-commits. In MySQL, the rollback-capable way to clear a table is DELETE FROM audit_log inside the transaction, at the cost of row-at-a-time delete work and undo-log space.

Migration implication

Postgres → MySQL migrations have to audit every TRUNCATE … CASCADE, TRUNCATE … RESTART IDENTITY, and every TRUNCATE inside a transaction block:

  • CASCADE — rewrite as an explicit ordered sequence of TRUNCATE or DELETE statements against the FK- dependent tables first.
  • RESTART IDENTITY — MySQL's TRUNCATE implicitly resets AUTO_INCREMENT; if the code relies on CONTINUE IDENTITY, the migration has to switch to DELETE and preserve the counter explicitly.
  • Transactional TRUNCATE — convert to DELETE inside the transaction. Pay the undo-log cost.

The PlanetScale post notes MySQL is likely to add these features in future releases; any migration plan should re-check current MySQL documentation rather than treating the 2023 gap as permanent.

Last updated · 378 distilled / 1,213 read