SQLite Storage Backend
Overview
TinyMUX 2.14 uses SQLite as its sole storage backend. All game data – objects, attributes, the communication system, and @mail – resides in a single SQLite database file. This replaces both the memory-based and disk-based storage modes from earlier TinyMUX versions, as well as the traditional flatfile dump cycle.
Write-Through Storage
Every mutation to the database is written through to SQLite immediately. When an attribute is set, an object is created, or a mail message is sent, the change is persisted to the database in the same operation. There is no separate in-memory store that periodically syncs to disk.
Crash Durability
Because writes are committed to SQLite immediately, the database is always consistent on disk. If the server crashes or is killed, no data is lost beyond the instant of the crash. There is no window of vulnerability between periodic saves, as there was with the traditional flatfile approach.
@dump and WAL Checkpointing
In TinyMUX 2.14, @dump performs a WAL (Write-Ahead Log) checkpoint rather than serializing objects to a flatfile. A checkpoint copies data from the WAL file back into the main database file. This is a lightweight operation that does not require forking a child process, does not pause command processing, and does not produce a separate flatfile. The @dump command still exists for administrative familiarity, but its behavior is fundamentally different from earlier versions.
Indexed @search
The @search command takes advantage of SQLite indexes for common query patterns. Simple searches – by name, type, owner, or zone – are routed to indexed SQL queries, providing O(log n) lookup time. This is a significant improvement over earlier versions where @search performed a linear scan of the entire object database.
JIT Code Cache
The JIT compiler stores compiled native code in the SQLite database. Cached code is keyed by the source expression and tagged with a JIT_COMPILER_VERSION. When the compiler version changes, stale entries are invalidated. Storing the code cache in SQLite means it persists across server restarts, so frequently-used softcode is not recompiled on every boot.
Connection Logging
Connection events are recorded in a connlog table within the SQLite database. Each row captures the player dbref, connect time, disconnect time, disconnect reason, site address, and related session metadata. This provides a queryable connection history without relying on external log file parsing.