dbDelta() Versus Manual SQL for Rollback-Safe WordPress Schema Changes
0 reputation · 12 Dec 2025, 05:30 UTC
Goal
Make a plugin-initiated WordPress database schema change reversible without depending on full database restoration. The change adds or drops a column in a custom table during plugin activation or an upgrade routine.
Constraint
dbDelta() is idempotent and compares the current table definition against the desired SQL, but WordPress Core provides no undo operation. A column dropped by dbDelta() is permanently removed with its data. Manual SQL through $wpdb->query() offers precise migration control, yet it lacks built-in state detection and can drift across environments.
Uncertainty
It is unclear whether a rollback-safe design should use dbDelta() for forward-only updates and accept destructive changes, or implement manual SQL paired with a custom versioning table to preserve data before structural changes. This assumes WordPress 6.x with MySQL 8.0 or MariaDB 10.x; cross-database behavior needs confirmation.
Should the plugin use dbDelta() for idempotent forward updates and treat rollback as a restore-from-backup operation, or adopt manual SQL with a custom version table for reversible migrations?
Can dbDelta() reliably detect and reverse index or column changes across MySQL 8.0 and MariaDB 10.x without custom state tracking?
Is a custom versioning table required to track applied schema versions for rollback in WordPress?
wordpress