Direct answer

A slow database can delay a plugin if queries or connection waits run on a critical server thread. A database warning does not automatically mean the entire server tick loop is blocked.

How to check it

  1. During the slowdown, start /spark profiler start --timeout 120 and examine call stacks for a specific plugin’s database operations or connection-pool waits.
  2. Correlate that period with plugin warnings such as query timeouts, locked SQLite files or lost connections. Do not publish passwords or full connection strings.
  3. Check storage capacity and latency if SQLite is in use, or network reachability and pool saturation for external SQL services.
  4. Test the same plugin action with production-like data in staging. Avoid changing the database engine until the bottleneck is demonstrated.
/spark profiler start --timeout 120
/spark profiler stop

What to change

Correct the slow query, blocked thread, overloaded remote service or plugin configuration identified by evidence. Keep a consistent backup of both the database and plugin configuration before upgrades or migrations.

Software and version notes

Database calls may happen asynchronously; profiler stacks must be interpreted with thread context. Switching from SQLite to MySQL without a validated migration can lose data.

Verify the result

Repeat the same in-game action and compare latency, plugin logs and profiler stacks. Confirm saved data remains consistent after restart.

References