If SQLite compatibility is non-negotiable, MongrelDB is not an SEE replacement. It does not open SQLite files and it does not implement SQLite’s API. The SQLite SEE alternatives guide starts with that dividing line, because comparing ciphers before comparing compatibility is how migration projects get approved for the wrong reason.

The bytes that actually get encrypted

MongrelDB stores immutable sorted runs in its own .sr format. Page payloads in encrypted runs use AES-256-GCM, so confidentiality and authentication travel together; changing ciphertext or its authentication tag causes open or read to fail rather than producing plausible corrupted plaintext.

Encrypted tables also protect WAL frames with AES-256-GCM, because leaving the newest writes in a plaintext log would make page encryption mostly theatre. Persistent result-cache entries are encrypted as well. Structural run headers, schema, manifest data, and index files are not blanket-encrypted, so the storage directory still reveals some metadata; the documentation names that boundary rather than claiming the directory is an opaque blob.

Per-column page statistics need special handling. Cleartext min and max values would leak useful information even if every row payload were encrypted, so encrypted-column statistics travel in an authenticated per-run envelope and are decrypted when the run opens, preserving page pruning without publishing those bounds in the cleartext directory.

The key hierarchy

A human passphrase first goes through Argon2id with a random salt, then HKDF derives the database key-encryption material. Every sorted run receives its own random 256-bit data-encryption key, and that DEK is wrapped by the database key rather than stored as usable plaintext. Columns marked as searchable derive separate per-column keys, while WAL, cache, checkpoint, and metadata domains use separate derivation contexts.

Applications that already have high-entropy key material can skip the human-passphrase work factor and open with a raw key derived through HKDF. Production operators can also use HashiCorp Vault Transit: MongrelDB generates a random database root key, asks Vault to wrap it, and stores only provider identity plus Vault ciphertext in the database metadata.

KMS rotation rewraps the stable database root key rather than rewriting every page. The rotation has a durable journal and can resume after a crash, which sounds like implementation trivia until the first maintenance window is interrupted halfway through; key management is mostly failure recovery wearing a cryptography badge.

All in-memory key values use zeroizing wrappers. If a required passphrase, raw key, or KMS is unavailable, open fails closed. If the only copy of the passphrase or root key is lost, the data is lost too, because a recovery back door would also be a decryption back door.

Searchable encryption is a separate trade

Ordinary page encryption lets a trusted process decrypt pages and evaluate general SQL. It does not make an index searchable by an untrusted operator without revealing anything. MongrelDB’s ENCRYPTED_INDEXABLE flag adds derived query material for the narrower case where selected equality or range filters must avoid a full decrypt-first scan.

Equality tokens use a keyed HMAC construction, so the same plaintext in one column produces the same index token. That enables exact lookup, but repeated values remain repeated tokens and frequency remains visible. Range tokens preserve enough order to resolve a bounded interval, which means order leaks by design. The searchable encrypted database guide covers that leakage directly; there is no honest version of searchable range encryption where the index learns nothing about order.

ColumnDef {
    id: 2,
    name: "account_id".into(),
    ty: TypeId::Bytes,
    flags: ColumnFlags::empty()
        .with(ColumnFlags::ENCRYPTED_INDEXABLE),
}

The page stores the encrypted value and the index stores its derived token. Use that flag only for columns with a real indexed-query requirement, because ordinary encrypted columns reveal less.

What it costs

The current documentation deliberately does not publish one universal encryption-overhead percentage. AES acceleration, page size, cache warmth, transaction size, storage device, fsync policy, and query shape all change the result, and a number measured on one workstation becomes marketing fiction as soon as it loses those qualifiers.

The repository includes a page-encryption benchmark command:

cargo bench -p mongreldb-core --bench page_encryption

Run it on deployment-class hardware, then repeat the application’s real write and scan workload with encryption enabled. Small synchronous transactions usually expose fixed crypto and durability costs more clearly than large sequential batches, while warm reads can hide much of the page-decryption path behind cache reuse.

The comparison that actually matters

SEE is the conservative choice when the product is already SQLite and official compatibility is worth the license. SQLCipher and other maintained SQLite codecs belong on the shortlist when open-source availability and SQLite compatibility both matter. MongrelDB belongs on a different shortlist, for applications willing to change engines because they also need columnar scans, DataFusion SQL, vector and sparse retrieval, searchable equality or range columns, or one WAL covering operational and analytical data.

The cipher name does not decide that architecture. File compatibility, key operations, failure recovery, metadata leakage, backups, and the queries the application must still answer decide it, the same way they did when encrypted storage meant an encrypted filesystem and a handwritten key file, only now there are more layers available to get subtly wrong.