Database

DaisyFilter persists through SculkData/HikariCP. SQLite is the default; MariaDB and MySQL are supported. PostgreSQL is deferred. DaisyFilter does not add Exposed.

Configuration

storage.yml carries the Sculk-compatible database keys plus DaisyFilter’s privacy, retention, and queue settings. Switching the backend requires a restart.

Tables

• df_schema_meta
• df_records — one row per logged violation (metadata; optional encrypted raw).
• df_staff_actions — privacy-safe audit trail for external punishment commands.
• df_rule_hits
• df_player_stats — coalesced per-player aggregates.
• df_warnings
• df_staff_notes
• df_staff_preferences

df_records is indexed by created-at, player, and surface for dashboard queries and keyset pagination.

Write path

Writes never block the event thread:

• a bounded append queue batches record writes off-thread;
• player statistics use Sculk’s write-behind store, coalescing repeated updates into one row per flush;
• queue depth, failures, retries, and dropped operations are counted and surfaced in /daisyfilter status;
• on shutdown the queues flush within a deadline.

If the database is unavailable, filtering continues in a degraded mode — matches are still censored/blocked and players still warned — while persistence retries. Errors are rate-limited and never include raw content.

Retention and purge

Records expire after a configurable retention period (default 30 days). A daily job purges expired rows in bounded batches. You can also purge manually with /daisyfilter purge <days> confirm.

See privacy.md for raw-content encryption and key handling.