Encryption at rest · embedded storage

SQLite SEE alternatives for embedded database encryption

SQLite SEE is SQLite's official paid encryption extension. Alternatives range from SQLite-compatible codecs to entirely different embedded engines. Compatibility should be the first dividing line, not the cipher name.

Short answer: choose SEE when official SQLite compatibility and support dominate. Evaluate SQLCipher or another maintained SQLite codec when SQLite compatibility plus open-source availability matters. Consider MongrelDB only when changing engines is acceptable and encrypted operational data also needs hybrid indexes, SQL analytics, or searchable equality/range columns.

Define the encryption requirement

“Encrypt the database” hides several separate questions:

  • Must the file remain SQLite-compatible?
  • Are the WAL, temporary files, result caches, backups, and index checkpoints covered?
  • Does the application use a passphrase, a random key, or an external KMS?
  • Must equality or range filters work without a full decrypt-first scan?
  • How are keys rotated and how does rotation recover after a crash?
  • What happens when the key is missing or wrong?

Encryption at rest protects stolen storage. It does not replace OS permissions, application authorization, TLS, backups, or endpoint security.

Option families

OptionSQLite compatibilityLicensing / modelPrimary reason to choose it
SQLite SEEOfficial SQLite extensionCommercial license from SQLite authorsOfficial integration and support
SQLCipherSQLite-compatible encrypted databaseOpen-source core with commercial offeringsEstablished encrypted SQLite ecosystem
Encrypted SQLite forks/codecsVaries by implementation and versionVariesSpecific platform, language, or licensing fit
MongrelDBNone; different engine and file formatMIT or Apache-2.0Encryption integrated with WAL, columnar runs, hybrid indexes, and SQL
Migration warning: MongrelDB is not a codec for SQLite and does not open SQLite files. Selecting it means changing database APIs, migration tooling, and operational assumptions.

What MongrelDB encrypts

MongrelDB encrypts sorted-run page payloads with AES-256-GCM. Encrypted tables also use frame-level AES-256-GCM for WAL segments and encrypt result-cache files. A passphrase is derived through Argon2id and HKDF, while high-entropy raw keys can skip the passphrase derivation step. HashiCorp Vault Transit can wrap the database root key externally.

Each run has its own data-encryption key wrapped by the database key hierarchy. Keys held in memory use zeroizing wrappers. If required key material is unavailable, open fails closed.

let db = Db::create_encrypted(
    "./mydb",
    schema,
    1,
    "my-secret-passphrase"
)?;

Losing the passphrase or root key makes the data unrecoverable. That is expected cryptographic behavior, so key backup and restore testing belong in the database runbook.

Decision checklist

  1. If the application must keep SQLite files and APIs, remove non-SQLite engines from the shortlist.
  2. Test the exact SQLite features and extensions your application uses.
  3. Verify WAL, journal, temporary-file, backup, and crash-recovery coverage.
  4. Measure on deployment hardware with encryption enabled.
  5. Document key generation, storage, rotation, loss, and incident recovery.
  6. Test a wrong key and an unavailable KMS; both should fail safely.
  7. Run restore drills before production data exists.
Inspect encrypted MongrelDB

MongrelDB Viewer

Viewer can open Direct databases with a passphrase or connect through an authenticated MongrelDB server. Follow its security guidance before using production roots.

Multiple database engines

Mongrel by VisorCraft

Use Mongrel when encrypted MongrelDB work sits beside SQLite and other database systems, terminals, containers, Kubernetes, and APIs.

Sources