Storage

storage.yml decides where player data lives: active channel, joined channels, personal toggles, language, nickname, ignore list, reply target, mutes, parties and, when enabled, the chat log.

SQLite (default)

plugins/Voxen/storage.yml

type: sqlite

Nothing else to configure. The database file is created in the plugin folder. Fine for a single server; each server keeps its own copy, so nothing follows players between them.

MySQL / MariaDB

plugins/Voxen/storage.yml

type: mysql
host: localhost
port: 3306
database: voxen
username: voxen
password: "secret"
table-prefix: voxen_
pool-size: 10
queue-size: 500
chat-log-batch: 100

type: mysql covers MariaDB as well. Use this on a network so settings, nicknames, ignores, mutes and parties are shared.

PostgreSQL

plugins/Voxen/storage.yml

type: postgres
host: localhost
port: 5432
database: voxen
username: voxen
password: "secret"
table-prefix: voxen_
pool-size: 10
queue-size: 500
chat-log-batch: 100

postgresql works as a value too. Mind the port: 5432, not 3306. The database and the user have to exist before the first start, Voxen only creates its own tables.

Tables

Every table is prefixed with table-prefix, so several plugins or several networks can share one database:

Table	Holds
voxen_players	per-player settings, nickname, reply target
voxen_ignores	ignore lists
voxen_mutes	active and expired mutes
voxen_parties / voxen_party_members	parties
voxen_chat_log	stored messages, only when history is enabled
voxen_schema	the schema version, used for automatic migrations

Schema updates run on startup. There is nothing to migrate by hand between plugin versions.

Each step checks what the database already has instead of trusting the recorded version, and the version is written as soon as its step finishes. A crash or a killed process halfway through an update leaves the database in a state the next startup can pick up from, so nothing gets applied twice and nothing gets skipped.

Writes that touch more than one row run in a transaction: parties, chat history batches and the schema version. Either everything lands or nothing does, so a dropped connection cannot leave a party without members. Player settings and mutes go through a single UPSERT, which is atomic on its own.

Pool size

pool-size is the HikariCP connection pool. 10 is right for almost everyone. Voxen does its database work on a single background thread, so raising it does not make anything faster.

Write queue

Writes are queued and handled on that background thread. queue-size caps how many may wait. When the database is down or too slow the queue fills up and further writes are dropped, with one warning every 30 seconds instead of a wall of them. Without a cap the queue would grow until the server ran out of memory.

Repeated writes for the same player collapse into one, so a player toggling something ten times in a row costs a single write rather than ten. Chat history is written in batches of chat-log-batch rows.

Both values take effect after a restart. Raise queue-size if a busy server logs drops during a short database hiccup; if it drops constantly, the database is the problem.

Going from one server to many

Switching from SQLite to MySQL starts from an empty database; existing SQLite data is not imported. Do it before the network goes live, or accept that players re-pick their channel and language once.

What is not stored

Slowmode, the global chat mute and channel mutes live in memory and are cleared by a restart. Mutes on players are stored, and on a network they are also broadcast live. See Cross-server chat.