Persistence

A few Mochi features keep server-side state that outlives a single request — queued jobs, cached values, rate-limit counters, spent captcha nonces. Each one defaults to in-memory storage and can be pointed at something durable instead.

Per feature

• Queues — in-memory by default. Point the serve-level queueStorage (or a descriptor’s storage) at a SQLite file ({ sqlite: path }), a Postgres database ({ postgres: url }), or an embedded PGlite instance ({ pglite }). One store serves every queue; Postgres storage is shared, so multiple processes can work one backlog.
• Cache — new MochiCache({ storage }). Defaults to MemoryStorage; FileStorage writes one JSON file per entry. Built-in SQLite and Postgres backends are planned; until then any other backend is a Storage implementation (getItem / setItem / removeItem / clear), with serialize / deserialize when the backend needs strings.
• Image cache — the one feature that persists by default: FileStorage under cacheDir. Pass image: { storage } to swap it (e.g. new MemoryStorage()); cacheDir is then ignored.
• Rate limiting — rateLimit: { store }. memoryStore() (default), sqliteStore({ path }) and postgresStore({ url }) all ship with the framework; MochiRateLimitStore is the interface for your own. Create the store once and share the instance across routes.
• Captcha — captcha: { store: 'memory' | 'sqlite' }, plus storePath for the SQLite file. A custom NonceStore needs only consume(nonce, expiresAt).

Choosing a backend