Consolidating the vector store into Postgres removed a second datastore

Summary: V1 ran Qdrant as its own container alongside the Postgres already used for session state. For V2 I moved vector search into that same Postgres via pgvector — one fewer datastore to run, secure, and back up, at no practical cost for this corpus size.

What was encountered

The corpus lived in Qdrant, a dedicated vector database running as a separate Docker container. That meant two datastores to operate — Qdrant and the Postgres holding patch_sessions — plus extra dependencies (qdrant-client, grpcio) and a container to keep alive, all for a modest corpus.

	V1	V2
Session state	Postgres (patch_sessions)	Postgres (patch_sessions) — unchanged
Vector search	Qdrant (separate Docker container)	pgvector inside that same Postgres
Total datastores	2	1

How it was solved

Moved vector search to pgvector inside the existing Postgres. The client kept the same interface (search() / upsert_entry() / init_collection()), so the change was close to a one-line import swap at the call sites. The Qdrant container and its deps can be removed once the V1→V2 migration finishes.

Reference: Vector database tradeoffs — at application scale, an extension on a database you already run beats a dedicated service whose extra performance you won't notice. Reach for the specialised store only when scale forces it.