DaisyVotes — Storage & Data

DaisyVotes stores all of its data through Sculk Data, the framework’s ORM. The default backend is SQLite, written to a database file inside plugins/DaisyVotes/ — there is no external database to install or configure.

storage.yml

backend: sqlite
file: "data.db"
remote:
  host: "localhost"
  port: 3306
  database: "minecraft"
  username: "root"
  password: "${DB_PASSWORD:-}"
  use-ssl: false
pool-size: 10

remote.* is only read once backend names a real server — SQLite ignores it entirely. password reads from an environment variable by default (${DB_PASSWORD:-}) so the shipped file stays a working example without a real secret sitting in a config anyone might paste into a support channel; replace it with a literal password if you’d rather set one directly.

Key	Default	Description
backend	sqlite	One of sqlite, mysql, mariadb, postgres (postgresql also works).
file	data.db	The SQLite file, relative to the plugin folder. Ignored for the remote backends.
remote.host	localhost	Remote server host or IP. Ignored by SQLite.
remote.port	3306	Remote server port. 3306 for MySQL/MariaDB, 5432 for Postgres — see below.
remote.database	minecraft	Database name.
remote.username	root	Database username.
remote.password	${DB_PASSWORD:-}	Database password. Defaults to reading the DB_PASSWORD environment variable; blank if unset.
remote.use-ssl	false	Connect over SSL/TLS.
pool-size	10	Connections kept open. More is not faster — a Minecraft server has one thread doing the asking. Range 1–64.

Note

SQLite is the right choice for the vast majority of servers — it’s fast, file-based, and zero-maintenance. For a multi-server network, use a shared MySQL/MariaDB (or Postgres) database instead (below).

Backend

Value	Dialect	Driver	Notes
sqlite	SQLite	bundled	Default. File-based, single-server only.
mysql	MySQL/MariaDB	MariaDB JDBC	See below — mysql and mariadb are the same setting.
mariadb	MySQL/MariaDB	MariaDB JDBC	Same as mysql; accepted spelling, use whichever matches your server.
postgres	PostgreSQL	PostgreSQL JDBC	Supported, but newer and less travelled than the other three — see below.

Note

mysql and mariadb are not two backends — they’re two accepted spellings of one setting. Either name selects the same dialect and the same MariaDB JDBC driver, which talks to both a real MySQL server and a real MariaDB server. Use whichever word matches the database you actually run; it makes no functional difference.

Ports: MySQL and MariaDB default to 3306 (remote.port’s shipped default). Postgres normally listens on 5432 — DaisyVotes does not change the default for you, so set remote.port: 5432 yourself when you switch backend to postgres.

What’s actually tested: SQLite and MySQL/MariaDB are the well-travelled paths — that’s what most installs run and what the test suite and support history cover. Postgres support is real (DaisyVotes ships the driver and creates the same tables), but it’s the newest of the four; if you hit something Postgres-specific, report it.

Multi-server (shared database)

Running DaisyVotes across a network of servers? Point every server at the same database in storage.yml instead of SQLite — MySQL/MariaDB is the proven choice here. That one shared database keeps vote counts, points, streaks, and the reward queue consistent everywhere — it’s the foundation a cross-server network is built on. Add Redis on top (in network.yml, not here) only if you want instant cross-server delivery and parties.

Caution

SQLite is single-server only. A network must use a shared MySQL/MariaDB (or Postgres) database — never point multiple servers at one SQLite file.

What’s stored

DaisyVotes keeps its data in a set of tables, created automatically on first run:

Table	Holds
vote_players	Per-player stats: total/daily/weekly/monthly votes, current & best streak, points & lifetime points, streak freezes, parties contributed, first/last vote timestamps.
vote_sites	Per-site totals.
player_site_votes	Per-player, per-site vote counts (drives cooldowns and the daily wheel set).
vote_events	An immutable history of every vote received (used for accurate period windows).
pending_rewards	Rewards queued for offline players, claimed with /vote claim.
vote_party_state	The global vote-party counter and party history.
wheel_states	Per-player available & lifetime wheel spins.
wheel_spins	History of wheel results.
shop_purchases	Purchase history, used to enforce daily limits.
top_voter_state	Tracks daily/weekly/monthly period rollovers.

Tip

Everything is written asynchronously — vote processing starts off the main thread before touching the database, and only returns to the main thread for player-safe actions like giving items. The plugin stores UUIDs and names, never long-lived player references.

Backups

The database is a normal file. To back it up safely:

1. Stop the server (so nothing is mid-write).
2. Copy the database file (and, if you like, the whole plugins/DaisyVotes/ folder) somewhere safe.
3. Start the server.

• Directoryplugins/DaisyVotes/

  • config.yml
  • menus.yml
  • rewards.yml
  • shop.yml
  • storage.yml
  • … the SQLite database file (back this up)

Resetting data

To wipe all vote data and start fresh, stop the server and delete the database file; DaisyVotes recreates it empty on the next start.

Danger

Deleting the database removes all vote counts, streaks, points, and history permanently. Back it up first.

Performance & caching

• Leaderboards are sorted, limited and ranked in the database itself, so there is no in-memory snapshot to go stale. stats.leaderboard-cache-seconds is no longer used as of 2.5.0 — the key is kept only so an existing config.yml still parses.
• PlaceholderAPI values are cached for ~10 seconds so placeholder lookups never hit the database on the main thread.
• Duplicate votes within sites.duplicate-window-seconds are dropped before any write.