WP-DBManager runs scheduled mysqldump-based backups, optimises core tables, and repairs corruption when it appears. The default admin screen lists backup files, exposes an Optimise Tables action, and shows a small log. Useful for the basics, less useful when you manage thirty sites and want to know which backup ran last night and whether wp_postmeta grew.

SleekView reads WP-DBManager's backup directory, its job history, and the live information_schema stats for each table. Backup files become rows with date, size, and status. Tables become rows with engine, row count, and last optimised date. Filters surface backups older than thirty days or tables that haven't been optimised this quarter.

Inline actions trigger WP-DBManager's own backup, optimise, and restore functions, so behaviour stays identical to the built-in screens. The grid is the new interface; the runner is unchanged.

WP-DBManager is one of the oldest backup plugins in the WordPress ecosystem, and on most sites it runs quietly in the background. The trouble starts when something goes wrong and nobody noticed: a failed dump for the past week, a table that hasn't been optimised since launch, or a backup file that's mysteriously zero bytes. The default screen is fine for a single admin who checks it weekly, but on a portfolio of sites or a team with rotation, that single screen does not scale.

SleekView gives backup verification a queryable, filterable surface. Site administrators verify last-successful backup at a glance, agencies standardise the daily check across every client site, and performance engineers track table growth as a metric. Triggers still go through WP-DBManager's own actions so behaviour and scheduling stay intact.

The result is a backup posture you can measure, share, and audit instead of trusting to a single screen and a single email.