MySQL Storage and Cross-Server Setup for Minecraft Plugins

Storage and cross-server sync are two different settings

The first question is where a plugin keeps its data on the server it runs on: a flat file, an embedded SQLite database that needs no setup, or a MySQL server you administer yourself. The second question is whether a second server behind a proxy sees the same state. They are only the same question when a plugin says they are, and in this catalogue one plugin says so. InfiniteShops synchronises across servers by pointing them at the same MySQL database: connect multiple servers to one database and limited stock, limited-sell quotas, dynamic prices and Daily Shop purchase limits stay consistent network-wide.

LPC Pro does both things, but not with one mechanism. It keeps persistent data in a database, and it has a separate proxy integration that carries chat between servers over plugin messaging rather than through that database; the two are configured in different files, integration/proxy.yml and database.yml. The docs recommend MySQL or MariaDB for BungeeCord and Velocity networks, and do not say whether the proxy features work on the default SQLite file — so do not assume either way. AntiAFKPlus states cross-server AFK sync over BungeeCord and Velocity in its record, and its documentation ties MySQL to multi-server setups — but neither source says what actually carries the AFK state between servers.

InfiniteCrops and InfiniteFishing offer MySQL as a storage choice and say nothing about networks. That distinction is the whole point of this page: MySQL as a storage backend is not the same promise as MySQL as a sync channel. Pointing two servers at one InfiniteFishing database is not something the record describes, and nothing in the repo says what would happen if you did.

Everything below comes from the product records in this catalogue and the on-site documentation imported from each plugin's own wiki. Where a record is silent, this page says it is silent.

What each plugin stores, and where

Five plugins here state a storage backend. Three state it in the product record itself; two state it only in their documentation, which is worth knowing before you plan a migration around a product page that never mentions a database. Minecraft ranges are the values on each record.

The defaults you get if you change nothing

Four of the five ship something that works before you have touched a database. LPC Pro uses SQLite with zero configuration, stored as a local lpcpro.db file inside the plugin folder, and its database page calls that the recommended option for single servers. The same page lists what is actually in there: player data, mutes, warnings, reputation, chat logs and more, across tables for channels and channel membership, ignore lists, mutes, warnings, staff notes, reputation and its transaction log, reports, polls and votes, offline messages, per-player settings, chat logs and statistics, achievements, quick replies, newcomer tracking, shop purchases and shop points, mail, and player language preferences. If you have been running LPC Pro for a year, that file is the server history, not a cache.

AntiAFKPlus is the same shape: its documentation FAQ says SQLite by default, stored in plugins/AntiAFKPlus/data/antiafkplus.db, with MySQL also supported for multi-server setups, and the first-install page shows that .db file in the generated folder tree next to config.yml and messages.yml.

InfiniteCrops defaults to SQLite with YAML and MySQL as the alternatives in config.yml, and its record adds the detail that matters for a crash: auto-save runs periodically to prevent data loss. InfiniteFishing is the outlier — JSON by default, MySQL if you choose it in config — and its record pairs that with async data processing, configurable save intervals, and an admin /infinitefishing forcesave subcommand — the record lists the name without describing what it does.

InfiniteShops is the one that needs reading twice. Its record says flatfile, per-player files, or MySQL for player data, with SQLite used automatically for internal storage — two different stores named in one sentence, and the per-player persistent disposal bins are stated to live in SQLite specifically. The config reference then ships a database block whose type is SQLite or MySQL, the configuration page repeats a near-identical block, and currencies documents a separate storage block of its own for custom-currency data. Nothing in the repo states how that one block relates to the three player-data options in the record, so treat the two statements as the two statements they are rather than assuming they describe one setting.

What actually crosses servers, and how it travels

This is where the differences get expensive if you guess. InfiniteShops syncs through the database; LPC Pro syncs through the proxy; AntiAFKPlus states the outcome and not the mechanism; the two gameplay plugins state nothing.

The InfiniteShops record is specific about what the shared database buys you, and specific is useful. A purchase on one server updates every connected server, so nothing oversells and limits cannot be dodged by switching servers. The shared economy data lives in MySQL and is restored automatically after a restart. The feature is optional and disabled by default, so single-server setups keep working exactly as before — you are not opting into a network by installing the plugin.

What the record does not claim is as useful. The four synchronised values are limited stock, limited-sell quotas, dynamic prices and Daily Shop purchase limits. It does not say player balances, shop definitions, transaction logs, Black Market auctions or shopper ranks travel between servers, so plan those as per-server until something in the plugin says otherwise. One more gap worth knowing before you open a support ticket: the on-site InfiniteShops documentation covers the database block in config.yml but does not document the cross-server feature at all — the product record is the only place the feature itself is documented. If you are standing the plugin up for the first time, the InfiniteShops setup guide covers the shop side of the same install.

LPC Pro solves the same problem a different way, and the difference is architectural rather than cosmetic. Its proxy page puts cross-server settings in integration/proxy.yml: enabled is false out of the box, each server needs a unique server-name such as survival, skyblock or hub, and sync-channels, sync-private-messages, sync-mutes and sync-announcements each default to true once the feature is on. Channels marked cross-server in the channel config are the ones that travel, a synced-channels list can override that, and a cross-server-format wraps incoming messages with the source server name. The transport is Bukkit plugin messaging: messages are serialised and sent through the proxy to every connected server running LPC Pro, which means the proxy needs plugin messaging enabled and every server needs the plugin — a mute applied on one server applies everywhere, and the transport for that message is plugin messaging; the proxy page does not say how mute state and the database interact.

AntiAFKPlus states the outcome plainly — AFK status follows players across your network on BungeeCord and Velocity, with every AFK value also exposed through PlaceholderAPI so other plugins can read state without hooking in directly — and pairs it with a bungee-send warning stage that moves an idle player to another server instead of kicking them. What it does not state anywhere in the repo is whether that sync rides the proxy, the database, or both. If the answer matters to your topology, ask before you build on it. For the broader picture of pairing it with menus, the server menus and AFK guide covers the feature side.

Setting up MySQL: what each plugin asks of the database

LPC Pro is the only plugin here whose documentation states hard database requirements, and they are the kind that fail a connection rather than degrade it: MySQL 8.0 or newer, or MariaDB 10.3 or newer, with the utf8mb4_unicode_520_ci collation, which the docs tie to emoji and unicode support. The database page gives the CREATE DATABASE statement with that character set and collation, and notes that LPC Pro creates every table it needs on startup. Configuration switches from type: local to type: remote, with host given as host:port on one line, plus database name, username and password. Connection pooling runs through HikariCP, which handles reconnection, and the JDBC connection string is customisable for anyone who needs to.

One operational detail on that page saves an evening: database.yml does not support reloading, so any change to it needs a full server restart, not a reload command. The LPC Pro FAQ adds the triage path when a connection fails — check the credentials, confirm the database exists with the right collation, confirm the MySQL server is reachable from the Minecraft server, and switch back to type: local to establish whether the problem is the database at all. Garbled non-English characters are treated separately there: add -Dfile.encoding=UTF-8 to the startup flags and make sure the database uses utf8mb4.

InfiniteShops asks for less. Its config block takes type (SQLite or MySQL), host, port 3306, database, username and password, plus a connection pool with max_connections and min_idle values you can tune. The docs also raise MySQL under performance rather than only under scale, listing a switch to MySQL as one of the responses to lag when opening shops, alongside reducing hologram update intervals and limiting search results. No minimum MySQL version and no collation requirement are stated for it anywhere in the repo.

InfiniteCrops and InfiniteFishing state the choice and stop there: config.yml supports YAML, SQLite or MySQL for the first, and JSON or MySQL set in config for the second. Neither states a minimum server version, a collation, a pool size, or what happens to existing data when you change the setting. Their deeper setup is covered in the custom crops guide and the fishing setup guide, neither of which adds a database requirement the records do not carry.

Where the records are silent

Honest gaps are worth more than a confident guess, because a guess here costs you player data. These are the things this catalogue does not state, collected so you can ask about them before you commit a topology. Two of them reach beyond the five plugins above: GUIPlus, whose player data page names the file its saved fields live in, and the crate and vehicle plugins, which name no storage at all.

• Which InfiniteShops player-data backend is the default — The record names flatfile, per-player files or MySQL without saying which applies out of the box, while the config reference ships a database block set to SQLite; how the two relate is not stated.
• Whether InfiniteCrops or InfiniteFishing data can be shared — Both offer MySQL as a storage backend and neither claims cross-server sync, so a shared database is not a documented configuration for either.
• What carries AntiAFKPlus AFK status — The record states BungeeCord and Velocity sync works out of the box and the docs state SQLite by default with MySQL for multi-server setups; nothing states which of them moves the AFK state.
• How to move existing data between backends — No record or documentation page in this catalogue describes converting live data from flatfile, JSON or SQLite into MySQL — the InfiniteShops /ishop convert command imports shops from other shop plugins, which is a different job.
• What GUIPlus does with per-player fields — Its documentation states that saved fields live in plugins/GUIPlus/playerData.yml keyed by player UUID, with no database option stated — so a balance saved by a bank menu is a file on one server.
• Storage for the rest of the catalogue — The crate plugins, GUIPlus and the vehicle plugins state no storage backend in their records, so treat any assumption about a database there as unverified.

Choosing a backend for the server you actually run

On a single server, the defaults are the documented recommendation rather than a compromise: LPC Pro calls SQLite the recommended option for single servers, AntiAFKPlus generates its .db file and asks nothing of you, InfiniteCrops runs an auto-save periodically to prevent data loss, and InfiniteFishing writes JSON on a save interval you control. The reason to move off them is stated as size, not correctness — the LPC Pro FAQ suggests switching from SQLite to MySQL for larger servers under high memory usage or lag, and the InfiniteShops docs suggest MySQL for large servers under performance.

On a network, work backwards from what you need to be true across servers. If limited stock or a Daily Shop limit must hold network-wide, InfiniteShops needs the shared MySQL database and the feature turned on, because it is off by default. If chat, mutes and private messages must cross servers, LPC Pro needs its proxy integration enabled with a unique server-name per server, and that is independent of whether you also move it to MySQL — though its docs do recommend MySQL or MariaDB for BungeeCord and Velocity networks. If AFK state must follow players, AntiAFKPlus states that it does on both proxies, and its docs state MySQL is supported for multi-server setups.

Two practical notes before you migrate anything. First, plan a backup of the existing files yourself: since no plugin here documents a converter between backends, changing the setting is a change you should assume starts from empty unless you have verified otherwise on a test server. Second, a database change is a restart for LPC Pro by documentation, and a restart is the safer assumption for the rest.

For the rest of the picture, the dependency guide covers what each plugin needs installed before it starts, the version support guide collects the Minecraft ranges, and the economy, chat, gameplay and utilities hubs put the plugins named here beside their siblings.