ChestShop, Database Migration Guide

When to Migrate ChestShop's Database

ChestShop stores transaction logs and shop ownership data in either a flatfile (SQLite/H2) or a MySQL database. Most servers start with the default flatfile because it requires zero setup. As your server grows past a few hundred active shops, the flatfile starts to slow down queries, especially transaction lookups and shop searches. That is when chestshop database migration to MySQL becomes necessary.

A MySQL backend also enables cross-server shop synchronization if you run a BungeeCord or Velocity network. With flatfile, each server instance has its own shop database with no way to share data. If you are planning to scale, migrating early saves you from a painful emergency conversion later.

Pre-Migration Checklist

Before starting any chestshop database migration, complete these steps:

1. Full server backup. Copy your entire plugins/ChestShop/ folder and your world files. If something breaks, you need a clean rollback point.
2. Inform your players. Shops will be inaccessible during migration. Post an announcement and schedule the migration during off-peak hours.
3. Verify MySQL access. Confirm you have a MySQL or MariaDB database ready with the connection credentials. On Astroworld Hosting, you can create a MySQL database from the Pterodactyl panel's database tab.
4. Update ChestShop. Run the latest version to ensure migration commands are available and bug-free.

Configuring MySQL in ChestShop

Open plugins/ChestShop/config.yml and update the database section:

database:
  type: MySQL
  host: localhost
  port: 3306
  database: chestshop
  username: cs_user
  password: your_password
  tablePrefix: cs_

Replace the credentials with your actual MySQL details. If your database runs on the same machine, localhost is correct. For remote databases, use the IP or hostname provided by your host.

Running the Migration

Stop the server. Change the database type in config to MySQL. Start the server. ChestShop detects that the configured backend differs from the existing data and offers to migrate automatically on startup. Watch the console for migration progress messages.

If automatic migration does not trigger, some versions require you to run a manual conversion command. Check the ChestShop documentation for your specific version. The process reads every record from the flatfile and inserts it into MySQL tables.

Validating the Migration

After migration completes, verify your data:

• Run /csstats to check that shop counts match pre-migration numbers.
• Have a player interact with an existing shop to confirm transactions work.
• Check the MySQL database directly to ensure tables were created and populated.

Keep your flatfile backup for at least two weeks after migration. If players report missing shops, you can cross-reference the original data. Use CoreProtect to inspect transaction history if you suspect data was lost during the switchover.

Migrating Back to Flatfile

In rare cases you might need to reverse the chestshop database migration, for instance if you downsize from a network back to a single server. The process is the reverse: change the config back to SQLite, restart, and ChestShop imports from MySQL into a new flatfile. Always back up both databases before any direction change.

Performance After Migration

With MySQL, ChestShop queries are significantly faster on servers with 500+ shops. Transaction logging, which writes a row on every purchase, benefits the most because MySQL handles concurrent writes better than SQLite. Your players should notice faster shop interactions and your console should show fewer database-related lag warnings.

For servers using ChestShop alongside ShopGUI+ and a Vault economy, having all three plugins on MySQL creates a unified database layer that simplifies backups and monitoring.

See these configs live: Astroworld MC, IP play.astroworldmc.com, Java + Bedrock.