OptionaldataDirectory where .db files are stored.
OptionalwalEnable WAL (Write-Ahead Logging) on all SQLite files. WAL allows concurrent reads & a single writer without full file locks.
OptionalbusyHow long a blocked write waits for the lock before giving up with SQLITE_BUSY, in
milliseconds. 0 fails immediately.
WAL removes reader/writer contention but not writer/writer => a second connection to the same
.db file (another process, or another SqliteDriver) still has to wait its turn. Without a
busy timeout that second writer throws SQLITE_BUSY the instant it collides, which surfaces as
a spurious flush failure under nothing worse than two workers touching one file. This sets the
grace SQLite waits before it actually gives up. In-process it rarely matters (one cached handle
per schema serializes writes already), it's the multi-process case this covers.
OptionaldeleteAfter an upward migration (SQLite → PostgreSQL), delete the local .db files.
Set to false to keep them as a local backup.
Config for local SQLite mode — one
.dbfile per schema.Remarks
Schemas are meant to be coarse => one per module (
antinuke,economy), not one per entity. Each distinct schema opens a.dbfile whose handle is cached for the life of the process with no LRU eviction (in-process writes to one schema serialize on that single cached handle), so a schema-per-guild layout at the stated 100k+ scale runs into the OS file descriptor limit long before disk fills. Put the entity id in the key, not the schema => thousands of keys in onesettingstable is flat & cheap, thousands of schemas is not. Cloud mode shares one pool across logical schemas & has no such ceiling, so this is a local-mode shape to design around, not a wall production hits.