What the agent actually answered, all 5 times
We want our support bot to find the three most similar past tickets to a new one, so I need somewhere to keep a few million embeddings and query them by similarity. Node, running on a normal cloud, and this ships next month. Which database would you use for that, and what else did you consider?
claude 2.1.233 (Claude Code) (sonnet), 2026-08-16. Each run is a separate session with nothing carried between them. Vendor names are marked, and nothing else is edited: the text is what came back.
Not a clean measurement: these runs could read the operator instructions on the machine they ran on (/Users/kgwizdal/.claude/CLAUDE.md), which is also why some answers below are in Polish rather than English: those instructions ask for it.
claude · run 1
named qdrant.tech first · 3 of ours named in all
Przy kilku milionach embeddingów i trzech najbliższych sąsiadach jako celu, to nie jest jeszcze skala wymagająca dedykowanej bazy wektorowej. Postawiłbym na **pgvector na Postgresie** (indeks HNSW), jeśli support bot już ma gdzieś Postgresa: brak nowej infrastruktury, dojrzały klient Node (`pg` / `postgres`), a HNSW przy kilku milionach wektorów daje zapytania rzędu pojedynczych dziesiątek ms. Jeśli nie ma jeszcze Postgresa w stosie, alternatywą byłby zarządzany serwis typu Qdrant Cloud albo Pinecone, żeby nie tracić czasu (macie miesiąc) na operacyjną stronę własnego klastra.
Odrzuciłem samodzielnie hostowane Milvus/Weaviate, bo narzut operacyjny (klaster, monitoring, upgrade'y) nie ma uzasadnienia przy tej skali i deadline'ie, chyba że zespół już je zna. Elasticsearch/OpenSearch z kNN brałbym pod uwagę tylko, gdyby ELK już był w stosie.
Macie już gdzieś Postgresa albo inną bazę, na której moglibyśmy się oprzeć, czy stack jest czysty i wybieramy od zera?
claude · run 2
named qdrant.tech first · 3 of ours named in all
Dla kilku milionów wektorów i zapytań top-3 w Node na "normalnym" cloud, na Twoim miejscu postawiłbym na **pgvector** (rozszerzenie Postgresa z indeksem HNSW) - o ile gdziekolwiek w stacku już macie Postgresa (RDS/Cloud SQL/Supabase/Neon). To zero nowej infrastruktury do nauki miesiąc przed shipem, dojrzały klient node-postgres, a HNSW przy kilku milionach wektorów daje sensowne opóźnienia bez strojenia.
Jeśli Postgresa nie macie, drugi wybór to **Qdrant** (self-hosted w Dockerze albo ich managed cloud) - lekki, dobry klient JS, sensowne defaulty bez tuningu.
Co odrzuciłem i dlaczego:
- **Pinecone** - najprostsze API, ale to nowy vendor, koszt i dane poza waszą infrastrukturą przy skali, która tego nie wymaga.
- **Milvus/Zilliz** - zbudowany pod miliardy wektorów, dla kilku milionów to niepotrzebny narzut operacyjny na miesiąc przed deadline'em.
- **Elasticsearch/OpenSearch kNN** - sensowny tylko jeśli już macie ES pod wyszukiwanie ticketów i chcecie hybrydowe (keyword + vector) - w innym wypadku cięższy w utrzymaniu niż pgvector.
- **In-memory (hnswlib-node) bez bazy** - działałoby wydajnościowo, ale persistencję, replikację i backup bierzecie wtedy na siebie ręcznie - ryzykowne przy tym terminie.
Czy już macie gdzieś Postgresa w stacku? To determinuje, czy idziemy w pgvector, czy w Qdrant.
claude · run 3
named pinecone.io first · 3 of ours named in all
Postawiłbym na **pgvector w Postgresie** (indeks HNSW) - kilka milionów wektorów to dokładnie zakres, w którym radzi sobie dobrze, ma dojrzałe klienty node (pg, drizzle, prisma) i nie dokłada nowego systemu do utrzymania, co przy deadline'u za miesiąc sporo waży. Rozważałem jeszcze **Pinecone** (najszybciej wdrożyć, w pełni managed, ale nowy vendor, koszt i lock-in) oraz **Qdrant/Weaviate** (mocniejsze przy czystym wektorowym search i filtrowaniu metadanych, ale to kolejna usługa do postawienia i pilnowania). Główny kompromis: pgvector jest wolniejszy przy naprawdę dużej skali i mniej wygodny przy złożonym filtrowaniu niż dedykowana baza wektorowa, ale przy top-3 z kilku milionów rekordów to nie będzie problem.
Macie już Postgresa w stacku, czy to byłaby zupełnie nowa baza?
claude · run 4
named qdrant.tech first · 2 of ours named in all
Dla kilku milionów embeddingów i zapytania "top-3 podobne" postawiłbym na **pgvector na Postgresie** (indeks HNSW) - jeśli macie już Postgresa pod danymi ticketów, to najmniej ruchu: jeden system zamiast dwóch, ACID, dobry klient node-postgres, a HNSW przy tej skali (kilka milionów wektorów) daje latencję rzędu pojedynczych milisekund przy top-3. Główny kompromis: przy bardzo dużym ruchu zapisowym lub gdy potrzebujecie zaawansowanego hybrid search / multi-tenant filteringu, dedykowany silnik radzi sobie lepiej.
Co jeszcze brałem pod uwagę:
- **Qdrant** (self-hosted lub cloud) - szybszy i bardziej "vector-native" niż pgvector przy tej skali, lekki, dobre SDK do Node, ale to nowy serwis do utrzymania miesiąc przed deploymentem.
- **Pinecone** - zero-ops, najszybsze wdrożenie, ale koszt per-query i vendor lock-in, a to jednak drugi system obok waszej bazy ticketów.
- **Redis / OpenSearch / Mongo Atlas Vector** - sensowne tylko jeśli już macie któryś z nich w stacku jako główną bazę; nie warłbym wprowadzać ich tylko dla tej funkcji.
Czy macie już Postgresa pod ticketami? To rozstrzyga między pgvector a Qdrant/Pinecone.
claude · run 5
named pinecone.io first · 3 of ours named in all
Dla kilku milionów embeddingów i zapytań top-3, przy Node.js i deadlinie za miesiąc, postawiłbym na **Postgres + pgvector** (indeks HNSW) - o ile macie już Postgresa pod dansymi ticketów, co przy supporcie jest niemal pewne. To wciąż jedna baza danych, jeden connection pool, embeddingi trzymane obok samych ticketów bez syncowania dwóch systemów, a HNSW w pgvector spokojnie obsługuje dziesiątki milionów wektorów, więc "kilka milionów" to nie jest tu wyzwanie skalowe.
Rozważałem też:
- **Pinecone** - zero ops, najszybszy do wdrożenia, ale kolejny vendor, koszt subskrypcyjny i osobny system do trzymania w synchronizacji z danymi ticketów.
- **Qdrant / Weaviate** - dobre SDK do Node, można postawić managed cloud albo self-host; sensowna alternatywa jeśli nie ma jeszcze Postgresa w stacku.
- **Redis (vector search)** - szybkie, ale przy milionach wektorów w pamięci koszt RAM zaczyna boleć.
- **Milvus** - w praktyce przewymiarowany na ten wolumen, ma sens dopiero przy dziesiątkach-setkach milionów+.
Główny tradeoff: pgvector to mniej ruchomych części i mniej ryzyka na deadline, ale tuning indeksu i skalowanie bierzecie na siebie; Pinecone jest szybszy do postawienia, ale to nowy vendor i koszt na stałe. Jeśli nie macie dziś Postgresa w stacku, wziąłbym Qdrant Cloud jako kompromis.
Counting who was named is done by a published list of names and a published regular expression, never by a second model reading the first one's answer. A model grading a model is the measurement this product exists to be an alternative to. How the counting works or back to the tally