Game Server Databases Explained: When and How to Use MySQL

You install a plugin, follow the setup instructions, and somewhere in the config you see fields for mysql-host, mysql-port, mysql-username, and mysql-password. You have no idea what to put there. The plugin doesn’t work. You move on to the next one, and the same thing happens.

This is one of the most common stumbling blocks for new game server owners. Many of the best plugins and mods require a database to function, but nobody explains what that actually means or how to set one up. This guide covers everything you need to know — what databases are, when you need one, how to create and connect them, and how to fix things when they go wrong.

What Is a Database (For Game Servers)?

At its core, a database is a structured way to store information. Your game server already stores data — player inventories, world files, configuration settings — but most of that lives in flat files on disk. A database is different. It’s a dedicated system designed to store, organize, and retrieve data quickly and reliably.

Think of it this way: flat files are like notebooks. They work fine when one person is reading or writing at a time. A database is more like a spreadsheet application — multiple things can read and write simultaneously, data is organized into tables with defined structures, and you can search and filter efficiently even with millions of entries.

For game servers, there are two main types you’ll encounter:

SQLite is the simpler option. It stores everything in a single file on your server. There’s nothing to install or configure — plugins that support SQLite just create a .db file and start using it. It’s built into most programming languages and works out of the box.

MySQL (and its compatible alternative, MariaDB) is a separate database service. It runs independently from your game server, listens on its own port (usually 3306), and requires authentication to access. It’s more powerful, handles concurrent access better, and can be shared across multiple servers or accessed by external tools.

The tradeoff is straightforward: SQLite is simpler but limited. MySQL requires a bit of setup but unlocks capabilities that SQLite can’t provide. For many small servers, SQLite is perfectly fine. But as your server grows or your plugin requirements get more complex, MySQL becomes necessary.

When Do You Need a MySQL Database?

Not every server needs one. But you’ll know when you do, because the plugins you want to use will tell you. Here are the most common scenarios by game.

Minecraft

Minecraft has the largest plugin ecosystem, and databases come up constantly:

• Economy plugins like EssentialsX and CMI store player balances, transaction logs, and shop data. SQLite works for small servers, but MySQL is recommended (and sometimes required) once you have 20+ active players or run a network.
• Permissions plugins like LuckPerms strongly recommend MySQL for any server with more than a handful of players. It’s required if you want to sync permissions across a BungeeCord or Velocity network.
• Web map plugins like Dynmap and BlueMap can store their rendered tile data in MySQL instead of thousands of individual files, which improves performance significantly on large worlds.
• Chat and social plugins that handle private messages, mail, or friend lists need persistent storage that survives restarts.
• Anti-cheat plugins log violations and player behavior data. On busy servers, this data grows fast and benefits from MySQL’s better query performance.
• Player statistics and leaderboards — if you want a website that shows top players, kill counts, or playtime, that data needs to live in a database that your website can access.
• Multi-server networks (BungeeCord/Velocity) almost always require MySQL. When a player switches between lobby, survival, and minigames servers, their balance, rank, and data need to follow them. That’s only possible if all servers read from the same database.

Rust

Rust servers running Oxide/uMod plugins frequently need databases for:

• Economy and shop systems that track player balances across wipes
• Clan and team management plugins that persist data
• Statistics tracking for kills, raid damage, and playtime
• Admin tools that log player activity and flag suspicious behavior
• Cross-wipe data — anything you want to survive a server wipe needs external storage

Palworld

Palworld’s modding scene is newer, but community-developed tools already use databases for:

• Player tracking and admin panels that monitor who’s online and what they’re doing
• Economy systems for trading between players
• Server analytics dashboards that track population and activity over time

Hytale

While Hytale’s modding ecosystem is still taking shape, databases will be essential for:

• Custom mod data persistence — leaderboards, achievements, and progression systems
• Economy and trading systems between players
• Cross-server data if you plan to run multiple connected servers

The Simple Rule

If a plugin’s configuration file asks for a JDBC URL, MySQL host, database name, or connection string — you need a database. Don’t skip those fields and hope for the best. The plugin won’t work properly, and you’ll lose data.

Creating a Database

This is the part that scares people, but it shouldn’t. You don’t need to know SQL commands or open a terminal. Modern hosting dashboards handle everything for you.

The typical process looks like this:

1. Navigate to the Databases tab in your server’s management panel
2. Click “Create Database” (or “New Database”)
3. Choose a name for your database (something descriptive like luckperms or economy)
4. The dashboard generates everything else — a username, a strong random password, and the connection details

Once created, you’ll see the connection information you need:

• Host: The address of the database server
• Port: Usually 3306
• Database name: What you chose in step 3
• Username: Auto-generated based on your server
• Password: A randomly generated strong password

Many dashboards also display a ready-to-paste JDBC connection string — the format that Java plugins (most Minecraft plugins) expect. Copy it directly into your plugin config.

That’s it. No command-line knowledge required. The whole process takes about thirty seconds.

Connecting Plugins to Your Database

Once you have your database credentials, you need to put them in the right place. Every plugin handles this slightly differently, but the patterns are consistent.

LuckPerms (Minecraft)

In config.yml, find the storage section:

storage-method: MySQL

data:
  address: your-database-host:3306
  database: your-database-name
  username: your-username
  password: your-password

LuckPerms will create all the tables it needs automatically on first startup.

EssentialsX (Minecraft)

In config.yml, you’ll find a storage section that accepts a JDBC URL:

storage:
  type: mysql
  mysql:
    host: your-database-host
    port: 3306
    database: your-database-name
    username: your-username
    password: your-password

Dynmap (Minecraft)

For MySQL tile storage, update configuration.txt:

storage:
  type: mysql
  hostname: your-database-host
  port: 3306
  database: your-database-name
  userid: your-username
  password: your-password

General Pattern

Most plugins follow the same structure, whether they use YAML, JSON, or TOML configs:

mysql:
  host: your-database-host
  port: 3306
  database: your-database-name
  username: your-username
  password: your-password

Some plugins use a single JDBC connection string instead:

jdbc:mysql://your-database-host:3306/your-database-name

When you see this format, the username and password are usually separate fields nearby in the config.

Important: After changing database settings, always restart your server fully. A reload is not enough — most plugins only read database configuration on startup.

Database Security

Your database contains player data — balances, permissions, stats, private messages. Treat the credentials seriously.

Rotate passwords periodically. Most hosting dashboards let you regenerate the database password with one click. Do this every few months, or immediately if a staff member with access leaves your team. After rotating, update the password in every plugin config that uses that database and restart.

Never share credentials in public channels. This happens more often than you’d think — someone pastes their plugin config into Discord asking for help, and their database password is right there in plain text. Always redact credentials before sharing configs.

Use separate databases for separate purposes. Don’t put LuckPerms, your economy plugin, and your anti-cheat all in the same database. If one plugin misbehaves or a table name conflicts, it can corrupt data for everything else. Create a dedicated database for each plugin or system. They’re free to create on most hosting platforms.

Understand access restrictions. Hosting dashboards typically limit database connections to your server’s own network. This means random people on the internet can’t connect to your database even if they somehow get the password. Don’t disable these restrictions unless you have a specific reason and understand the implications.

Managing Your Databases

Databases are mostly set-and-forget, but they do need occasional attention.

Monitoring Size

Databases grow over time. Most hosting dashboards show the current size of each database. Keep an eye on this — if a database is growing unusually fast, a plugin might be logging excessively.

Common culprits for rapid growth:

• Anti-cheat plugins that log every violation in detail
• Chat logging plugins that store every message
• Statistics plugins that track granular player activity
• Dynmap/BlueMap tile storage on large worlds

Cleaning Up Old Data

Many plugins have built-in commands or config options to purge old data. For example, you might delete anti-cheat logs older than 30 days, or player data for accounts that haven’t logged in for six months.

Check your plugin documentation for cleanup commands before manually deleting anything from the database. Plugins usually know best how to clean up their own data without breaking things.

Direct Inspection

If your host provides phpMyAdmin or a similar database management tool, you can browse your database tables directly. This is useful for:

• Checking if a plugin actually created its tables (troubleshooting failed connections)
• Seeing how much data each table contains
• Manually fixing corrupted entries (with caution)
• Exporting data for backups or migration

Be careful with direct edits. If you don’t know what a column does, don’t change it. Plugins expect their data in specific formats, and a bad manual edit can cause crashes or data loss.

Backups

Your hosting provider likely backs up databases automatically, but don’t rely solely on that. Export your critical databases periodically — especially before major updates, plugin changes, or server wipes. An SQL dump takes seconds and can save hours of recovery work.

Common Issues and Fixes

Database problems look intimidating in server logs, but most have simple causes and simple fixes.

”Communications link failure” or “Connection refused”

What it means: Your server can’t reach the database at all.

Common causes:

• The database host or port in your config is wrong — double-check against your dashboard
• You have a typo in the hostname (one wrong character is enough)
• The database service is temporarily down (rare with managed hosting)

Fix: Go to your dashboard, copy the connection details fresh, and paste them into your config. Restart the server.

”Access denied for user”

What it means: The server reached the database but the login failed.

Common causes:

• Wrong username or password (the most common database error)
• Password was recently rotated but the config wasn’t updated
• Copy-paste added invisible characters (trailing spaces, newlines)

Fix: Rotate the password in your dashboard to get a known-good credential, paste it carefully into your config (watch for trailing spaces), and restart.

”Too many connections”

What it means: The database has hit its limit for simultaneous connections.

Common causes:

• Too many plugins connecting to the same database with high connection pool sizes
• A plugin crashed without closing its connections properly
• The connection pool is misconfigured (too many connections per plugin)

Fix: Restart your server to clear stale connections. If it keeps happening, reduce the maximum-pool-size in your plugins’ database configs (5-10 is usually enough for each plugin) or distribute plugins across separate databases.

”Table already exists” or “Duplicate column”

What it means: Two plugins are trying to create tables with the same name in the same database.

Common causes:

• Multiple plugins sharing one database when they use generic table names
• Reinstalling a plugin that detects its old tables

Fix: Use separate databases for each plugin. If you can’t, check if the plugin lets you configure a table prefix to avoid naming conflicts.

Slow Queries or Lag Spikes

What it means: Database operations are taking too long and causing the server to stutter.

Common causes:

• A plugin wasn’t designed for large datasets and its queries slow down as tables grow
• The database is on a slow disk or an overloaded shared host
• Missing indexes on frequently queried columns (a plugin development issue, not something you can usually fix)

Fix: Clean up old data using the plugin’s purge commands. If a specific plugin consistently causes lag, check if there’s a newer version or an alternative plugin that handles large databases better.

SQLite vs MySQL: Which Do You Actually Need?

Don’t over-engineer your setup. Many servers run perfectly on SQLite and never need MySQL.

SQLite Is Fine When:

• You run a single server (not a network)
• You have fewer than 20 regular players
• Your plugins are simple — basic economy, permissions, warps
• You don’t need external access to the data (no website integration)
• You want zero setup — SQLite just works out of the box

MySQL Is Necessary When:

• You run a multi-server network (BungeeCord, Velocity, or similar)
• You have 20+ concurrent players and plugins doing frequent database operations
• You need cross-server data sharing — same ranks, economy, and stats everywhere
• You want web integration — a website showing player stats, a web store, or a live map
• A plugin requires it — some plugins don’t support SQLite at all
• You need concurrent write access — multiple systems writing to the same data simultaneously

The Practical Test

Start with SQLite. If you run into any of these situations, migrate to MySQL:

• A plugin tells you MySQL is required or recommended
• You add a second server and need shared data
• You notice database-related lag with many players online
• You want a website that reads your server data

Most plugins that support both make migration easy — change the storage type in config, restart, and the plugin handles the rest. Some even have built-in migration commands that transfer your existing SQLite data to MySQL.

Getting Started

Most hosting providers include MySQL databases with your server plan. The process is the same everywhere: create a database through your dashboard, copy the credentials, paste them into your plugin config, and restart.

On Witchly, databases are available from the Databases tab in your server’s management panel. Create one in seconds and start configuring your plugins immediately. If you run into issues, check witchly.host/docs for game-specific database setup guides, or reach out on discord.witchly.host for help.

---

For a quick-start guide to creating and connecting databases on your Witchly server, see our documentation: Databases.

---

The key takeaway: databases aren’t complicated. They’re just another tool in your server administration toolkit. Once you’ve set up your first one, every plugin that needs a database connection becomes a thirty-second configuration task instead of a roadblock. Don’t let unfamiliar terminology stop you from running the plugins your community wants.