cost: Qdrant memory footprint is the main driver of ~$36/mo Railway spend — enable on-disk vector/HNSW storage

[autojack-bot]

Summary

A read-only investigation of the AutoMem project's Qdrant service on Railway (2026-08-12) found that memory residency, not CPU or replica count, is the dominant cost driver.

Findings

• Railway usage --json for the current billing period: Memory $14.44 of $15.46 total (~93%), CPU $0.62, Volume $0.31, Backup $0.02.
• Qdrant sits at ~1.15–1.2 GB resident RAM 24/7 while CPU utilization averages 0.02% (~0.0066 vCPU) — essentially idle but billed for constant memory residency.
• Root cause in code: automem/stores/runtime_clients.py's ensure_qdrant_collection() creates the collection with bare Qdrant defaults — no on_disk=True on VectorParams, no on-disk HnswConfigDiff, no on_disk_payload — so vectors, index, and payload are fully RAM-resident by default.
• Volume is over-provisioned (50 GB allocated, ~1.5 GB used / 3%), but Railway's volume billing line item is small — low-impact hygiene fix, not the main lever.
• No replica/region scale-out issue (1 replica, single region, ON_FAILURE restart policy) — nothing to trim there.

Recommendation

1. Enable on_disk=True on VectorParams, add HnswConfigDiff(on_disk=True), consider on_disk_payload=True; migrate the existing (small, ~1.5 GB) collection to pick it up. Qdrant's own benchmarks show this config serving 1M vectors in ~135MB RAM (https://qdrant.tech/articles/memory-consumption/), vs. our current full in-RAM residency for a much smaller corpus.
2. Shrink qdrant-volume from 50 GB → ~5–10 GB.
3. No action needed on CPU/replicas — nothing to gain there.

References

• https://qdrant.tech/documentation/manage-data/storage/
• https://qdrant.tech/articles/memory-consumption/

Originating investigation was read-only (sandboxed agent run) and could not file this issue directly; filing now with the findings intact.