High availability and limits

High availability is declared per service from the real code of the installed version (ADR-0166). For the AI memory the answer is simple: neither engine has a replicated mode.

Mem0: single instance

The descriptor declares cluster, ha, failover, replication and quorum as none, one mode single and one fault domain. Reasons read in the code of v2.2.1:

• the history of the memories and the recent messages used as extraction context live in a local SQLite file (HISTORY_DB_PATH);
• the rate limits of the authentication routes are counted in memory, per process;
• the migrations run at each start.

Two servers behind a load balancer would each keep a partial history. The loss of the server stops the memory API until it is restarted or restored; the memories, vectors, users and keys stay in PostgreSQL. With the highly available PostgreSQL service, a lost host is replaced by a reinstall and the restore of the history file.

Cognee: standard profile as a single instance

The standard profile combines PostgreSQL (relational metadata and pgvector) and embedded LadybugDB 0.19.0 on a persistent volume. LadybugDB is an embedded engine whose files are locked by one process; the official entrypoint starts one gunicorn process. Two APIs would each keep a different graph. No distributed nor replicated mode is offered. A lost host is replaced by a reinstall and the restore of the last backup (database, LadybugDB files and data root taken together).

Graph backends not offered

• The PostgreSQL graph backend of Cognee 1.6.6 (postgres_demo) is a demo that the source code declares not ready for production: it is never presented as ready for banking production.
• Neo4j, Neo4j Aura and Neptune are excluded (licence or cloud service). Turso is not a validated engine of the platform.
• The advanced profile of ADR-0174 (external graph under an allowed licence, tenant isolation validated by a test) has today no backend that meets these conditions.

No capacity announced

No throughput, no latency, no number of memories and no graph size is guaranteed: no load test was run. The thresholds of the preflight checks (memory, CPU, disk) are installation minimums, not a capacity. The settings that bound the load are limit_concurrency (Mem0, 64 concurrent requests by default, 503 beyond), max_concurrent_pipelines (Cognee, 2 concurrent pipelines by default) and request_timeout_s (Cognee, 3600 seconds).

What was verified for real

The tests navin-manager/server/tests/test_mem0_real.py and test_cognee_real.py render the python method of the descriptor with the context of the Manager and run it for real against a real PostgreSQL 16.14 with pgvector 0.8.5, provisioned by the command of the postgresql descriptor.

Point	Mem0	Cognee
Sources or package	the 24 server files identical to the v2.2.1 archive	cognee 1.6.6, real LadybugDB 0.19.0
Database and role	role mem0 without privilege, migrations at revision 006	role cognee owner of its database only
Authentication	401 without a key, registration closed, user keys created then revoked	401 without a key, upstream account absent, key stored as a hash
Cycle	add with extraction, search, update, history, restart, deletion	add, cognify, extracted relations, searches CHUNKS, GRAPH_COMPLETION, RAG_COMPLETION, SUMMARIES, restart, deletion of one item
Isolation	-	two users separated, opened by a read permission
Backup	backup, verify, restore, upgrade migration	backup, verify, loss, restore
Functional test of the descriptor	every step passed, key masked	every step passed, key masked
Outbound traffic	none	none

Important limit: no real model server was used. The gateway is a deterministic OpenAI compatible server of the test, reached like LiteLLM at <url>/v1. Mem0 was tested with the default names local-llama and bge-m3-vllm (vectors of 1024); Cognee with the test names navin-chat and navin-embed. The quality of extraction and answers with a real model is therefore not measured. Only the python method is run by these tests; the podman method of Cognee, its interface and its MCP server are not.