Files
ThothII/docs/adr/0018-use-postgres-for-memory-and-qdrant-for-retrieval.md
T
Codex 82e2c91f42
Publish documentation / publish (push) Successful in 1m27s
feat: implement memory and evidence administration with guided repairs
Add PostgreSQL-backed memory, editable evidence with source review and activation, and human-approved archive repairs across the harness, API, and UI. Include migrations, deployment support, regression coverage, and validation documentation.

Refresh permissions from validated session roles so existing administrator logins can access newly deployed archive management features.
2026-09-10 10:31:34 +02:00

60 lines
3.0 KiB
Markdown

---
status: accepted
date: 2026-09-08
---
# Use PostgreSQL for Memory and Qdrant for retrieval
The new Memory module uses the installation's existing PostgreSQL service as the
authority for Memory Cards, their links, and structured schema dependencies.
Qdrant holds a rebuildable search projection. This replaces the JSONL registry and
allows related administrative changes to be coordinated in one database transaction.
The owner accepted this direction in Q9 of the Memory design interview; implementation
is pending.
Memory uses its own tables and remains a separate module from the Metadata Catalog.
Sharing the PostgreSQL service does not transfer Memory ownership to Database
management or make Evidence and Memory one canonical domain.
## Retrieval and graph
The owner also accepted hybrid semantic/lexical Qdrant retrieval with scope filters
and explicit card links traversed in core. Both belong to the planned first version;
there is no dedicated graph database or external Memory framework.
This extends [ADR 0017](0017-separate-reference-vectors-from-runtime-memory.md):
the separate reference and memory collections remain, while Memory gains sparse
lexical indexing in addition to dense vectors. Memory projections become rebuildable
from the module's PostgreSQL authority. Preprocessing Clear still preserves Memory;
this decision does not add it to the preprocessing cleanup scope.
Links support discovery. Finding a card through a link does not approve its use.
The core proposes links with the cards for the same final review; Administration
provides manual creation, editing, and deletion. Deleting a card removes its incident
links without deleting the other linked cards.
## Considered options
- Retaining JSONL preserves the current storage format, but leaves coordinated
card/link/dependency mutations and concurrent administrative writes to application code.
- Using Qdrant as the sole authority is a viable alternative for record storage and
retrieval. PostgreSQL is preferred for the coordinated mutations of the new module,
with Qdrant reserved for its search projection.
- Adding a dedicated graph database would introduce another service; the selected
bounded traversal can be implemented in core over persisted links.
## Consequences
The module needs a persistence contract, PostgreSQL schema, and explicit propagation
of additions, updates, and deletions to Qdrant. Choosing PostgreSQL does not make this
propagation atomic across both systems: failures, retries, and invalidation of stale
search content must be handled and tested. An index rebuild uses the original card
content and cannot resurrect deleted cards.
The decision does not introduce Memory revision history or require compatibility with
existing development sessions. Evidence authoring and publication remain governed by
their own contract until the Evidence management project defines its evolution.
The [Memory management project](../plans/2026-09-08-memory-management.md) records the
approved behavior, scope, and integration work.