Available right now
All prices net, plus VAT.
You buy the licence directly from us and get an invoice from us. Install by upload in the admin without SSH, updates through our licensing platform, support straight from the developer.
How to clean up your Shopware database in a scheduled, safe way - with dry-run, audit log and scheduled tasks.
Shopware 6.7, PHP 8.1 or newer, MySQL 5.7.4 or MariaDB 10.3 upwards - the latter because of session timeouts via MAX_EXECUTION_TIME. Automatic cleanup needs a running worker.
Upload the plugin in the Shopware admin, install and activate it. The module then appears under Extensions, Database Cleanup & Optimizer.
The module shows the current situation, manual cleanup, the settings for automatic runs and the log.
Every time an order is edited in the admin, Shopware creates a working copy - a draft. If the edit is cancelled instead of saved, that draft stays behind in the order and order_line_item tables.
Over months this adds up. Eventually admin forms such as the line items view start timing out because they have to work through tens of thousands of orphaned rows. Those are exactly the rows this plugin removes.
Only rows meeting both conditions are deleted:
0fa91ce3... is never touched.state_machine_history and are not version-bound. They are not touched.Dependent tables such as order_address, order_delivery and order_transaction clean themselves up through the foreign keys, so nothing is left behind.
The top area shows live how many orphaned order and line item versions exist, and how many of them are older than seven days. That is the honest answer to whether a run is worth it at all.
Running the preview before the first real cleanup is worthwhile - it costs nothing and shows the scale.
Cleanup can run on its own. You can set the interval - hourly, every 2, 6 or 12 hours, daily or weekly - along with the minimum age and how long log entries are kept.
messenger:consume. Without one, nothing happens.Every real run is logged, whether triggered from the admin, the console or automatically. Time, trigger, user, number of deleted rows and duration are recorded.
While a job runs, the footer shows a seconds counter. The job can be aborted at any time; DELETE batches already in flight are finished cleanly so the database stays consistent.
The first command only reports what would be deleted. The second actually cleans up, with a progress bar in the terminal.
--age-days, -a Default: 7--batch-size, -b Default: 50000--dry-run, -d--force, -fIf the tables are already causing trouble, this sequence has proven itself:
Ideally inside a tmux or screen session so the run survives a dropped connection. Afterwards enable automatic cleanup, daily with a seven day minimum age, and the tables stay clean for good.
InnoDB only marks deleted pages as free and does not hand the space back to the file system. Only this command actually reclaims it:
If a run unexpectedly deletes zero rows, this endpoint helps find the cause:
It returns exact counts, sample version IDs and a test DELETE inside a transaction that is rolled back immediately. It changes nothing.
--age-days=0 with care: Without the age filter, edits in progress can be destroyed - someone is editing an order and the draft is deleted from under them. The seven day default is the safe value.Either there is nothing to delete, or all candidates are younger than the minimum age. The diagnostic endpoint shows which it is.
That is normal. Only OPTIMIZE TABLE releases the space.
There is no active worker. Without the admin worker or messenger:consume no scheduled task runs.
Use the console for very large tables. The admin is subject to the HTTP timeout, the terminal is not.
We are happy to help with the first run on a large database - get in touch via the contact page or write to info@stoneandwater.online.
Every setting of the plugin with its default value and explanation, in the same order as in the administration. The texts come straight from the plugin (version 1.0.24).
Only delete versions older than X days. The default of 7 protects active edit sessions. 0 = no age filter (careful!).
How many rows are removed per DELETE statement. Higher = faster, but longer table locks. Allowed: 100 to 1,000,000. Recommended: 50,000 (default), for very large tables also 100,000-250,000. Allowed range: 100 to 1000000.
When active, cleanup runs at the configured interval via scheduled task.
How often the automatic cleanup should run: hourly, every 2, 6 or 12 hours, daily or weekly.
Only delete versions that are at least X days old.
Log entries older than X days are removed automatically. 0 = keep forever.
Safety filter for phase 4 (aggressive). Lower = more is cleaned.
Additionally remove ALL non-live commits older than X days, even if their version still exists. Recommended after large cleanups.
Deletes log_entry rows older than X days. 0 = empty the whole table (all entries).
Tables smaller than X MB are hidden.
Lists orders that have more than X entries in the order table (including the live version).
Two routes, the same feature set - pick whichever suits your setup.
All prices net, plus VAT.
You buy the licence directly from us and get an invoice from us. Install by upload in the admin without SSH, updates through our licensing platform, support straight from the developer.
The plugin will be listed in the official Shopware Community Store. Installation and automatic updates then run through the plugin manager, billing through your Shopware account. We will link it here as soon as it is live.
All features on the product page. We are happy to help with setup and cleanup strategy.