Yes. WP-CLI runs the .sql file against the current database, which typically begins with DROP TABLE IF EXISTS statements for each table. The result is a clean replacement of the existing data, not a merge. This is why the export step before import is critical — anything not in the backup file will not exist after the import.

Run grep 'siteurl' backup.sql | head -5 before importing. The siteurl value in the dump shows which site and domain the backup came from. If it shows a localhost or staging URL, you will need to run wp search-replace after the import to fix all domain references.

WP-CLI reads the database host, name, user, and password directly from wp-config.php. You do not need to pass credentials on the command line. This is why wp db import backup.sql works without any additional flags.

The database may be in a partially restored state. First, check the error message — it usually points to a specific table or SQL statement. If the import file is valid, try running it again (WP-CLI’s import is generally idempotent for standard WordPress dumps because each table is dropped before recreating). If the file itself is corrupted, you need an earlier backup.

wp db export is a thin wrapper around mysqldump that reads credentials from wp-config.php automatically. The resulting .sql file is compatible with wp db import and standard MySQL import tools. The main advantage over raw mysqldump is that you do not need to manually pass host, user, password, and database name on the command line.

The backup captures the database state at the time it was made. If WordPress core or any plugin was updated after that backup, the current PHP code expects a newer schema. wp core update-db applies any pending ALTER TABLE and schema changes that the code expects but the restored database does not yet have.