Embedded vector database with encryption at rest: what must be protected?

Start with the attacker, not the cipher

Inventory every vector database artifact

• Source rows and embeddings: raw text and vectors may both be sensitive.
• Write-ahead log: recent inserts and updates can appear before compaction.
• ANN and sparse indexes: graph edges, vector codes, token weights, or checkpoints can reveal structure or content.
• Metadata: schemas, dimensions, collection names, file sizes, and index definitions can disclose workload details.
• Temporary and result files: query output may bypass primary storage encryption.
• Backups and exports: copies need the same or stronger controls than the live directory.

A vendor statement that “the database is encrypted” is incomplete without this storage inventory.

Embeddings are not harmless anonymized data

Vector representations can preserve information about source content and membership. Treat them as derived sensitive data when they originate from private text, images, user behavior, or proprietary documents. Quantization changes representation and memory use; it is not encryption.

Approximate search also needs vectors or a searchable representation available to the trusted query process. Disk encryption protects dormant bytes, not values after authorized decryption in process memory.

MongrelDB encryption boundaries

MongrelDB documents AES-256-GCM encryption for sorted-run page data. Encrypted tables also use frame-level AES-256-GCM for WAL segments and encryption for result-cache files. Passphrases use Argon2id and HKDF; high-entropy raw keys can skip passphrase stretching; Vault Transit can wrap the database root key.

The documented inventory keeps structural headers, manifests, schema, and index metadata outside page-payload encryption. Current releases can evolve checkpoint handling, so verify the exact source and package version rather than inferring coverage from the table setting alone.

Encryption at rest is different from searchable encryption

At-rest encryption lets a trusted process decrypt data and query normally. Searchable encryption creates derived structures that support selected predicates while exposing controlled leakage.

MongrelDB's ENCRYPTED_INDEXABLE columns support equality tokens and order-preserving range tokens for compatible scalar lookups. They are not an encrypted ANN scheme. Equality can reveal frequency and range tokens reveal order; use them only when the query need justifies that leakage.

Key and recovery requirements

1. Generate high-entropy machine keys or enforce a strong passphrase policy.
2. Keep keys outside the database directory and backup set.
3. Define rotation, interrupted-rotation recovery, and KMS-unavailable behavior.
4. Verify a wrong key fails closed without modifying data.
5. Back up key metadata separately and test a complete restore.
6. Remove retired copies and exports under a documented retention policy.

Lost key material can make encrypted data unrecoverable. A recovery process that has never been exercised is not a recovery process.

Encrypted vector database evaluation

1. Create a database containing distinctive synthetic rows and embeddings.
2. Search every file, WAL segment, index artifact, cache, backup, and export for recognizable bytes.
3. Reopen with the right key, wrong key, and unavailable KMS.
4. Crash during write, checkpoint, backup, and key rotation.
5. Measure ingest, search, rebuild, and restore with encryption enabled.
6. Review memory, logs, telemetry, and model-provider disclosure separately.