Shopware writes to the log_entry table continuously. Every API call, every failed plugin action, and every system event generates log rows. By default, Shopware does not automatically purge old log entries. After one year of normal operation, a busy Shopware store can accumulate 10 to 30 million rows in this table alone.

The problem is that the Shopware admin dashboard and activity log views query this table on load. With tens of millions of rows and no cleanup schedule in place, these queries perform full or partial table scans that take two to four seconds on their own. This is a primary reason why the Shopware admin panel is slow — and it gets worse every week as more rows accumulate.

Beyond the Shopware log table itself, the message_queue_stats and dead_message tables grow in a similar pattern. Dead message queue rows from failed background jobs accumulate silently and contribute to admin slowdowns on any page that loads queue-related data.

• ✦Check the row count withSELECT COUNT(*) FROM log_entry;. If the count exceeds 500,000 rows, truncating or archiving old entries will produce an immediate speed improvement in the admin.
• ✦Truncate Shopware log table entries older than 30 days using:DELETE FROM log_entry WHERE created_at < DATE_SUB(NOW(), INTERVAL 30 DAY);. Run this during low-traffic hours on production. For very large tables, delete in batches of 50,000 rows to avoid locking.
• ✦Schedule a recurring database maintenance task to purge old log rows weekly. Add this as a MySQL event or a server cron job so the table never grows back to the same size.
• ✦Also clear thedead_messagetable if it has more than a few thousand rows. Rows in this table represent failed background jobs that will never be retried. They serve no operational purpose and only add query overhead.
• ✦After truncating, runOPTIMIZE TABLE log_entry;to reclaim disk space and rebuild the index. MySQL does not automatically reclaim space after bulk deletes without this command.

The Shopware admin list views — orders, products, customers — allow sorting and filtering on many columns. Each of these sort and filter operations translates into a SQL query with an ORDER BY or WHERE clause. When the column being sorted or filtered does not have a database index, MySQL performs a full table scan instead of using an index lookup.

On a table with 10,000 rows, a full table scan is fast enough not to notice. On a table with 500,000 orders or 200,000 products, the same unindexed query takes three to six seconds. This is a textbook case of why Shopware admin performance degrades with scale — the admin was designed for the data volumes at launch, not for what the database looks like two years later.

Custom fields added through plugins are a common culprit. Plugins often add columns to core Shopware tables without adding the corresponding database indexes. The admin then allows filtering on those columns, and every filter query triggers a full scan.

• ✦Enable MySQL slow query logging on your server and set the threshold to 1 second:SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 1;. After one day of normal admin usage, the slow query log reveals exactly which queries are causing the most delay.
• ✦RunEXPLAINon the slowest admin queries. Look fortype: ALLin the output — this confirms a full table scan. Any query withtype: ALLon a large table needs an index added to the column in the WHERE or ORDER BY clause.
• ✦Add missing indexes withALTER TABLE order ADD INDEX idx_order_date (order_date);. Use pt-online-schema-change from Percona Toolkit for adding indexes to very large tables without locking them during business hours.
• ✦Review plugin-added columns in theproductandordertables. Check if these columns are used for filtering in the admin and add indexes where they are missing.

The Shopware 6 admin is a Vue.js single-page application. Plugins extend this application by injecting their own components, watchers, and API calls. Well-built plugins register their code only on the admin routes where they are actually needed. Poorly built plugins register their API calls and watchers globally — meaning they run on every page in the admin, whether relevant or not.

A single badly written plugin might add 200 to 400 milliseconds of overhead per admin page load. With six or seven such plugins installed, the cumulative impact is one to three seconds of extra load time on every admin navigation. This is why Shopware admin slowdown often correlates directly with how many plugins are installed — even plugins that are unrelated to the page being viewed.

• ✦Open the browser developer tools in your Shopware admin. Go to the Network tab and navigate between admin pages. Look for API calls that fire on every route and whose origin is not core Shopware. These are the plugin calls adding overhead.
• ✦Disable plugins one at a time via the Shopware admin extension manager and measure admin load time after each disable. This binary search process identifies which specific plugin is responsible for the most overhead.
• ✦For plugins you cannot remove, check if an updated version is available. Plugin developers often fix performance issues in later releases. Updating a plugin to its latest version sometimes eliminates the unnecessary global watchers.
• ✦If you have custom plugins developed for your store, audit the admin module registration code. Ensure that API calls and data watchers are registered only inside the specific admin components where they are needed — not in the global module bootstrap.

PHP compiles source code into bytecode every time a file is executed — unless OPcache is enabled. OPcache stores compiled bytecode in memory so PHP skips recompilation on subsequent requests. For the Shopware admin, which loads dozens of PHP files per request, OPcache makes a large difference in response time.

When OPcache is disabled or configured with too little memory, every admin page load recompiles the Shopware PHP files from scratch. This adds 300 to 800 milliseconds to each request depending on server speed.

Over a full working day of admin usage, this overhead is substantial. Shopware backend slow responses caused by OPcache are easy to confuse with database problems. In both cases, the symptoms look identical from the outside.

• ✦Check OPcache status by creating a temporary PHP file with<?php phpinfo(); ?>on your server and searching for the OPcache section. Confirm thatopcache.enableis On and thatopcache.memory_consumptionis at least 256MB for a Shopware production install.
• ✦Set the recommended OPcache values in yourphp.inior a customopcache.inifile. The key settings for Shopware are:opcache.memory_consumption=256,opcache.max_accelerated_files=20000, andopcache.validate_timestamps=0for production.
• ✦Setopcache.validate_timestamps=0on production servers only. This setting tells PHP never to check whether a file has changed on disk, which is safe on production but will cause issues on development servers where code changes frequently.
• ✦After changing OPcache settings, restart PHP-FPM withsystemctl restart php8.2-fpm(adjust the version number to match your PHP version). Then clear the Shopware cache withphp bin/console cache:clearto ensure fresh compilation.

Every visitor to your Shopware storefront creates a session record and potentially a cart record. Guest shoppers who abandon their carts leave behind rows in the cart and sales_channel_api_context tables. Without a cleanup schedule, these tables accumulate millions of rows from visitors who will never return.

The Shopware admin panel queries these tables indirectly when loading certain dashboard widgets and order-related views. Large cart and session tables also create table lock contention — MySQL locks the table briefly during writes, and with millions of rows, these locks start causing perceptible delays across the database, including on admin queries that touch related tables.

• ✦Run the Shopware scheduled task for cart cleanup via the CLI:php bin/console scheduled-task:run shopware.cart.cleanup. This removes expired cart records using Shopware’s built-in cleanup logic.
• ✦Verify that the Shopware scheduled task runner is active on your server. Go toSettings → System → Scheduled Tasksin the admin and confirm that tasks show recent last-run timestamps. If tasks are not running, the cart and session cleanup never fires.
• ✦Configure the cart expiry time in your Shopware.envfile. The default is 120 days, which is far too long for guest carts. SettingSHOPWARE_CART_EXPIRE_DAYS=7for guest sessions keeps the table size manageable without affecting logged-in customer carts.
• ✦For stores with very large existing tables, run a manual batch delete to clear old data before relying on the scheduled task going forward. Delete in batches to avoid prolonged table locks during the cleanup.