CortexDB is the long-term memory layer for AI agents. The platform ships an operational backup path designed specifically for disaster recovery to protect sensitive memory states.
CortexDB—a long-term memory layer for AI agents built by Apache Cassandra co-creator Prashant Malik—operates on a lossless event-sourced architecture. Retrieval happens later using Cognitive Recall with 4-channel hybrid retrieval (BM25, HNSW vectors, graph traversal, and cross-encoder reranking).
Why does disaster recovery matter for AI agents?
AI agents require persistent context to function across multiple sessions. Catastrophic data loss effectively deletes the agent's entire lived experience, returning the agent to a permanent first-day employee state.
Most teams attempt to solve memory by relying on vector-only systems. RAG retrieves static docs to provide knowledge, which represents what is true about the world for everyone. Memory represents what is true about one specific agent in the world. Losing a vector index in a RAG pipeline means the index must simply be regenerated from static knowledge documents, but losing agent memory destroys unrecoverable interactions.
Alternative memory layers attempt to store lived experience differently. Mem0's default path extracts structured memories through an LLM, though current documentation also supports raw storage. Zep builds temporal knowledge graphs from chat and business data. CortexDB takes a different approach by treating every incoming interaction as an immutable event stored safely on disk.
CortexDB separates the durable log from the derived views. The raw event remains the source of truth, protected by continuous WAL archival and scheduled checkpoints. Summaries, embeddings, and knowledge graphs function as derived artefacts built asynchronously. We built this architecture to ensure point-in-time recovery works flawlessly during major incidents.
How does CortexDB manage backups?
CortexDB relies on periodic RocksDB checkpoints to capture the durable state of the system. The platform pushes these backups to object-store upload targets including local storage, S3, GCS, or Azure, utilizing provider-specific encryption modes.
Write-ahead log (WAL) segments archive continuously alongside the base backups. Point-in-time recovery (PITR) rehydrates the most recent base backup and replays these archived WAL segments to recover data up to any exact moment between scheduled backups.
The restore process completely rebuilds every derived view. Because the event log acts as the single source of truth, the vector index, knowledge graph, fulltext index, content store, and memory state are all reconstructed accurately during recovery without transporting them directly within the base backup.
What do these backup capabilities enable?
Three consequences matter most for operators.
Granular recovery allows operators to recover the system to the exact state immediately preceding an incident. WAL archival ensures no events are lost between scheduled checkpoint backups.
Schema upgrades execute automatically during the restore process. Derived views are rebuilt from raw events against the current extractor and indexing code, meaning a restore on a newer CortexDB version generates views matching the updated schema.
Cloud flexibility supports enterprise environments natively. CortexDB targets S3, GCS, and Azure blob storage using standard encryption modes (such as S3 SSE-KMS and GCS CMEK) to meet strict compliance standards.
Frequently asked questions
What is CortexDB's backup architecture?
CortexDB ships an operational backup path with RocksDB checkpoint backups, object-store upload targets, WAL archival for point-in-time recovery, and restore-time rebuilding of vector, graph, fulltext, content, and memory-state stores from the event log.
What is point-in-time recovery in CortexDB?
Point-in-time recovery (PITR) rehydrates the most recent base backup and replays archived WAL segments to recover to any moment between scheduled backups. The restore rebuilds every derived view from the recovered event log.
Which object-store targets does CortexDB support?
CortexDB supports four targets: local storage, S3 (including S3-compatible stores like MinIO), GCS, and Azure Blob Storage (including the Azurite emulator). Each target supports provider-appropriate encryption configurations.
How does the restore rebuild derived views?
Derived views function entirely as downstream derivatives of the event log. A restore replays the log against the current extractor and indexing code, producing views that match the running version's schema exactly.
How is the backup path different from export and import?
The backup path represents the operational disaster recovery path containing checkpoints, WAL archival, and automated restores. Export and import represent the logical portability path using newline-delimited JSON dumps for data migrations.
What encryption modes does CortexDB support for backups?
CortexDB supports AES256, aws:kms, aws:kms:dsse, and sse-c for S3. GCS relies on CMEK through service accounts. Azure targets utilize storage-service encryption handled at the account level.