pgvector vagy vektoradatbázis? Így válassz vektortárolót 2026-ban

Minden RAG-projekt ugyanabba a megbeszélésbe fut bele. Valaki megnyit egy diát hat vektoradatbázis-logóval, valaki más azt mondja, „hiszen már van Postgresünk”, és a vita ízlésbeli kérdéssé válik. 2026-ban ez a vita kevésbé arról szól, melyik motor a leggyorsabb, inkább arról, mit üzemeltetsz már, hogyan szűrik a lekérdezéseidet, és kit hívnak éjjel, ha az index összeomlik.

Szállítottam már keresést relációs adatbázisokra, keresőmotorokra és dedikált vektortárolókra épülve. Őszinte összegzésem: a választás ritkán múlik benchmarkon. A szűrésen, a hibrid keresésen, a memórián, a hosztoláson és az üzemeltetésen múlik, nagyjából ebben a sorrendben. Ez a cikk ezt az ötöt járja végig, a végén döntési ábrával és összehasonlító táblázattal.

Egy megjegyzés a bizonyítékokról. Minden konkrétum a gyártók saját dokumentációjából és kiadási jegyzeteiből származik, amelyeket 2026 október első napjaiban olvastam. Benchmarkszámokat szándékosan nem idézek: a vektor-benchmarkok az adathalmaztól, a recall-célszinttől, a hardvertől és a szűrőktől függnek, a keringők pedig többnyire a gyártók saját mérései. Ahol küszöböt mondok, jelzem, hogy az az én ítéletem.

A rövid válasz

Egy mondatban: használd azt a tárolót, amelyet a csapatod már tud üzemeltetni, és csak akkor hagyd el, ha meg tudod nevezni a mért korlátot, ami kényszerít. A legtöbb európai B2B-csapatnál ez Postgrest jelent pgvectorral, vagy a már üzemeltetett keresőmotort.

A cikk többi része megmagyarázza, miért, és hogyan derítheted ki, melyik helyzetben vagy. Ha magát a keresési réteget még tervezed, előbb olvasd el a RAG-pipeline útmutatómat a chunkolásról, hibrid keresésről és rerankingről: a tároló a kisebb döntés.

Mit tud ma a pgvector

A pgvector sokat változott a kezdeti, csak IVFFlat-es napok óta. A changelog megmutatja a RAG szempontjából fontos mérföldköveket, a legfrissebb kiadás, amit láttam, a 0.8.7 volt, 2026. október 1-jei dátummal.

• A HNSW indexek a 0.5.0-ban jelentek meg (2023 augusztus), a párhuzamos IVFFlat-építéssel együtt.
• A halfvec és a sparsevec a 0.7.0-ban jött (2024 április), a bináris kvantálási függvényekkel és a bit típus indexelésével együtt.
• Az iteratív indexszkennelések a 0.8.0-ban jöttek (2024 október), ez az a funkció, amitől a szűrt lekérdezések rendesen viselkednek.
• A javítókiadások számítanak. A 0.8.3 (2026 június) javította a HNSW vacuumolás közbeni lehetséges indexsérülést, a 0.8.4 pedig egy HNSW-javítási hibát, ezért maradj a legfrissebb 0.8.x javítón.

A README dokumentálja a korlátokat, amelyek köré tervezned kell. Egy vector oszlop 2000 dimenzióig indexelhető, a halfvec 4000-ig, a bit 64 000-ig, a sparsevec pedig 1000 nem nulla elemig. A HNSW alapértékei m = 16, ef_construction = 64 és ef_search = 40. Az index akkor épül a leggyorsabban, ha a gráf elfér a `maintenance_work_mem` keretében, a halfvec pedig lehetővé teszi ugyanazon embeddingek indexelését feleakkora tárhellyel: egy `embedding::halfvec(1536)` jellegű kifejezést indexelsz, és ugyanazzal a castolással kérdezel.

A pgvector valódi érve az indexen túl van: az embeddingek azok a sorok mellett vannak, amelyeket leírnak. A joinok, tranzakciók, sorszintű jogosultságok, mentések és a pontra visszaállítás azok, amelyeket már üzemeltetsz. Egy törölt ügyfél egy helyen törlődik, ami a GDPR miatt számít. Amit feladsz, az az izoláció: a vektorlekérdezések és indexépítések az OLTP-forgalommal versengenek memóriáért és CPU-ért, hacsak nem használsz replikát.

Ha kinövöd a sima pgvectort, de Postgresben maradnál, a pgvectorscale StreamingDiskANN indexet, statisztikai bináris kvantálást és címkealapú szűrt keresést ad a PostgreSQL licenc alatt. Írásakor a Timescale Cloudon a menedzselt kínálat privát béta volt, és a gyártó által közölt benchmarkok pontosan olyan számok, amelyeket a te adataidon újramérnék, mielőtt hinnék nekik.

A szűrésen dőlnek el a döntések

A valódi RAG-lekérdezés sosem az, hogy „e vektor legközelebbi szomszédai”. Hanem az, hogy „e vektor legközelebbi szomszédai azok között a dokumentumok között, amelyeket ez a felhasználó láthat, ezen a nyelven, ebből az évből”. A közelítő index egy gráfon sétál, és az utólag alkalmazott szűrő eldobja az eredményeket.

A pgvector ebben egyértelmű. Az alapértelmezett 40-es hnsw.ef_search mellett egy olyan WHERE-feltételű lekérdezés, amely a sorok nagyjából 10 százalékára illik, jellemzően a 40 jelöltből csak körülbelül négyet tart meg. Az iteratív szkennelések ezt javítják: állítsd a `hnsw.iterative_scan` értékét `strict_order` vagy `relaxed_order` értékre, és az index addig szkennel tovább, amíg elég sor egyezik, vagy el nem éri a `hnsw.max_scan_tuples` értéket (alapértelmezés 20 000). A `relaxed_order` mellett az eredmények kissé rossz sorrendben jöhetnek, a README pedig megmutatja, hogyan állítod vissza a sorrendet materializált CTE-vel.

• Kevés különböző szűrőérték: a README részleges indexeket javasol.
• Sok különböző érték, például bérlőnként egy ügyfél: particionáld a táblát.
• Alacsony találati arány: egy hagyományos B-tree index a szűrőoszlopon, hogy a Postgres pontos szkennelést választhasson.

A dedikált rendszerek a szűrést tervezési célnak tekintik. A Qdrant payload indexeket javasol minden mezőn, amelyre szűrsz, és támogatja a beágyazott must, should és must_not feltételeket, valamint tartomány-, térbeli és teljes szöveges feltételeket. Az OpenSearch hatékony szűrést dokumentál, ahol a Faiss és a Lucene motor is a gráfbejárás közben alkalmazza a szűrőt, így a megszorító szűrők is pontos top-k-t adnak. Az Elasticsearch a kNN-szűrőjét előszűrőként írja le, amely a közelítő keresés közben érvényesül. A Pinecone a rekordok metaadatain szűr a lekérdezés-végrehajtóiban.

A gyakorlati teszt egyszerű, és minden projektben lefuttatom: vedd az öt legszelektívebb valódi szűrőt, futtass mindegyikkel 200 valódi lekérdezést a szükséges recall mellett, és nézd meg, hány találat jön vissza és hogyan viselkedik a késleltetés. Párosítsd címkézett értékelő készlettel, ahogy a LLM-értékelések termékfunkciókhoz cikkemben leírom, hogy a válasz minőségét mérd, ne csak a sebességet.

Hibrid keresés: beépítve vagy magad építve

A sűrű vektorok elvétik a pontos tokeneket, például alkatrészszámokat, hibakódokat és neveket, a B2B katalógusok pedig tele vannak velük. Szinte minden komoly RAG-rendszer a végén kulcsszavas és vektoros keresést kombinál, ahogy a RAG 2026-ban: hibrid, ügynöki és hosszú kontextus cikkben érvelek.

A motorok abban különböznek, mennyit kapsz ebből készen. A Qdrant egy lekérdezésben támogatja a sparse és dense vektorokat, Reciprocal Rank Fusionnel és Distribution-Based Score Fusionnel, beágyazott prefetch-szakaszokkal és többvektoros támogatással ColBERT-szerű újrapontozáshoz. A Weaviate párhuzamosan futtatja a BM25 és a vektoros keresést és egyesíti őket, alapértelmezetten relative score fusionnel és 0,75 alapértékű alpha paraméterrel. A Milvus egy collectionön belül több vektormezőt, sűrűt és sparse-t is át tud keresni. A Pinecone támogatja a sparse vektorokat, a hibrid lekérdezéseket és a BM25-alapú teljes szöveges keresést. Az OpenSearch és az Elasticsearch elsősorban keresőmotor, így a BM25 és a vektorok egy indexben élnek.

A Postgres az építőelemeket adja: teljes szöveges keresést tsvectorral és rangsorolt vektoreredményeket a pgvectorból, Reciprocal Rank Fusionnel egyesítve SQL-ben. Ez nagyjából harminc sor, amely a tiéd és tesztelhető, jó csere, ha egyetlen tranzakciós tárolót értékelsz. Ha a csapatod nem akarja birtokolni a fúziós kódot és a körülötte lévő relevanciahangolást, az jogos ok a Weaviate-re vagy a Qdrantra, vagy arra, hogy keresőmotorban maradj.

Egy döntési ábra

Ebben a sorrendben teszem fel a kérdéseket. Szándékosan a már üzemeltetett rendszerek felé hajlik.

Két fenntartás. Az első „igen” nem zárja le a beszélgetést, ha a korpusz óriási: végezd el a memóriaszámítást a skálázásról szóló részben. A tartalék ágon a „kezdj pgvectorral” az én elfogultságom kis csapatok esetén, mert ez a legkönnyebben visszafordítható opció: egy migrációhoz elég a vektorok és a metaadatok exportja.

A lehetőségek egymás mellett

Ez a táblázat sűríti azt, amit a dokumentációban ellenőriztem. A verziók a legfrissebb kiadások, amelyeket 2026 október elején láttam a GitHubon: Qdrant 1.19.1, Weaviate 1.39.8, Milvus 3.0.2, OpenSearch 3.9.0 és pgvector 0.8.7.

Néhány részlet a cellák mögött. A Weaviate HNSW, flat, dynamic és HFresh indextípust kínál, ahol a dynamic egy küszöb felett (alapértelmezés 10 000 objektum) vált flatről HNSW-re, és sok kis bérlőhöz illik. A Milvus HNSW, IVF, DiskANN, ScaNN és GPU-indexeket, valamint állapotmentes, szétválasztott architektúrát dokumentál. Az Elasticsearch dokumentációja szerint a 384 vagy több dimenziós float vektorokat tartalmazó új indexek alapértelmezetten BBQ HNSW-t használnak. Az OpenSearch a Lucene (HNSW) és Faiss (HNSW és IVF) motorokat támogatja.

Skálázási küszöbök és költség

Az egyetlen küszöb, amit benchmark nélkül megadhatok, aritmetika. Egy float32 vektor dimenziónként 4 bájt. 1536 dimenziónál ez 6144 bájt, így 1 millió vektor nagyjából 6,1 GB-ot, 10 millió nagyjából 61 GB-ot igényel a gráfkapcsolatok, metaadatok és replikák előtt. A halfvec ezt nagyjából 3 GB-ra és 31 GB-ra felezi, a bináris kvantálás ennél jóval jobban zsugorít, olyan recall-áron, amit mérned kell.

A HNSW a gráfját memóriában akarja, így a gyakorlati kérdés az, hogy ez a memória elfér-e azon a gépen, amelyet amúgy is bérelnél. A hüvelykujjszabályom, és ez ítélet, nem mérés: néhány millió chunkig egy jól méretezett Postgres-példány ritkán a szűk keresztmetszet. Valahol a tízmilliók környékén, vagy amikor az indexépítések az elsődleges adatbázist terhelni kezdik, elkezdem összevetni a lemezalapú vagy kvantált lehetőségeket a dedikált rendszerekben.

• Saját üzemeltetésű vagy menedzselt Postgres: a költség a példány, amelyet amúgy is fizetsz, plusz a többlet RAM. Nincs új szállító.
• Keresőmotor-klaszter: node-onként fizetsz memóriáért és lemezért, de megosztod a kulcsszavas kereséssel és a logokkal.
• Dedikált felhőszolgáltatás: kapacitásért vagy használatért fizetsz. A Weaviate főként vektordimenziók szerint számláz, így az alacsonyabb dimenziójú vagy tömörített embeddingek közvetlenül csökkentik a számlát.
• Rejtett költség: a második rendszer második szinkronpipeline-t, második hozzáférési modellt és második incidenscsatornát jelent.

A költség a választott embeddingektől is függ. Egy kisebb modell, vagy olyan, amely rövidített vektorokat támogat, mindenhol csökkenti a tárhelyet. A tágabb eszközöket a LLM-költség, késleltetés, prompt caching és routing cikkben tárgyalom.

EU-s hosztolás és adatvédelem

Európai ügyfeleknél a „hol vannak a vektorok” beszerzési kérdés. Az embeddingek a dokumentumaidból származnak és információt szivárogtathatnak azokról, ezért kezeld személyes adatként, ha a forrás az.

• Postgres: egy menedzselt szolgáltató bármely EU-régiója, vagy a saját szervereid. A legegyszerűbb auditálni.
• Pinecone: dokumentálja az AWS eu-west-1 (Írország) és eu-central-1 (Frankfurt), valamint a GCP europe-west4 (Hollandia) régiót a Builder csomagtól felfelé. A Starter csomag az AWS us-east-1-re korlátozott, és a régió létrehozás után nem módosítható.
• Weaviate Cloud: EU-régiók a megosztott és a dedikált telepítéseknél, a bring-your-own-cloud opció „hamarosan” jelzéssel szerepel.
• Qdrant: menedzselt klaszterek AWS-en, GCP-n és Azure-on, valamint a Hybrid Cloud, egy önmenedzselt opció.
• Saját üzemeltetésű Milvus, Qdrant, Weaviate, OpenSearch: te döntöd el az adatközpontot, és te viszed az üzemeltetést.

Egy frankfurti régió szükséges, de nem mindig elégséges: egy amerikai székhelyű szolgáltatónál továbbra is felmerülhetnek kérdések a külföldi hozzáférésről, az embedding modell hívása pedig egy második adatfolyam. Ezt a részt a GDPR és LLM API-k: EU adatrezidencia cikkben tárgyalom. Szerződéskötéskor nézd meg a szolgáltató oldalán az aktuális régiólistát, mert ezek változnak.

Üzemeltetési teher

Ez az a költség, amit a benchmarkok sosem mutatnak. Tedd fel négy kérdést bármelyik lehetőségnek.

• Mentés és visszaállítás: vissza tudod állítani a vektorokat és a metaadatokat egy konzisztens időpontra? A Postgresben ez megoldott. A többinél a visszaállítást teszteld, ne csak a mentést.
• Újraindexelés: az embedding modell cseréje a korpusz újra-embeddingjét jelenti. Fel tudod építeni az új indexet a régi mellett és átkapcsolni?
• Frissítések: az olyan pgvector-javítások, mint a 0.8.3, indexsérüléseket javítottak. Ki figyeli a kiadási jegyzeteket?
• Ügyelet: egy elosztott rendszer Kubernetesen más elköteleződés, mint egy kiterjesztés egy olyan adatbázisban, amelyet már üzemeltetsz.

Tapasztalatom szerint a legolcsóbb üzemeltetés az, ha eggyel kevesebb rendszert futtatsz. Ez a pgvector és a keresőmotorok teljes érve, és ezért a menedzselt dedikált szolgáltatás a helyes válasz, ha a csapatodnak nincs kedve egyiket sem üzemeltetni.

Ellenőrzőlista döntés előtt

1. Írd le az öt legfontosabb szűrődet, a bérlői és jogosultsági ellenőrzésekkel együtt.
2. Számold meg a chunkokat, a dimenziókat és a növekedést, majd végezd el a memóriaszámítást float32-re és halfvec-re.
3. Építs címkézett értékelő készletet legalább néhány tucat valódi kérdésből.
4. Futtasd ugyanazokat a lekérdezéseket a két legjobb jelöltre a valódi szűrőiddel, és hasonlítsd össze a recallt és a késleltetést.
5. Döntsd el, ki felel a fúzióért és a relevanciahangolásért a hibrid keresésnél.
6. Kérd írásban az EU-régiót, a mentési, visszaállítási és frissítési eljárást.
7. Tervezd meg az újra-embedding útvonalát, mielőtt az első millió vektort betöltöd.

Ha két opció döntetlen, válaszd azt, amelyiknek kevesebb mozgó alkatrésze van. Később mindig válthatsz: a vektorok és a metaadatok tisztán exportálhatók.

Én mit tennék

Egy tipikus európai B2B-projektnél, ahol a katalógus vagy tudásbázis az alacsony milliós chunkszám tartományban van, pgvectorral, halfvec-kel, HNSW indexszel és iteratív szkennelésekkel kezdenék, hibrid kereséshez hozzáadnám a Postgres teljes szöveges keresését, az értékelő készletet pedig az első napon megírnám. Ha az ügyfél már üzemeltet OpenSearch-öt, ott tárolnám a vektorokat.

Dedikált vektoradatbázisra akkor váltanék, ha mért korlát jelenik meg: szűrt recall, amelyet az iteratív szkennelések nem mentenek meg, termelést terhelő indexépítések, vagy olyan bérlőkezelés és skála, amelyet a Postgresnek nem kellene vinnie. És a funkciói mellett éppúgy az üzemeltetési modellje alapján választanám, legyen menedzselt vagy saját üzemeltetésű az EU-ban. Ha segítség kell a döntéshez a saját adataidon, nézd meg az AI-engineering munkámat.

Források

1. pgvector README (index limits, HNSW defaults, iterative scans, filtering, halfvec)
2. pgvector CHANGELOG (0.4.0 to 0.8.7)
3. pgvectorscale: StreamingDiskANN, statistical binary quantization, filtered search
4. Qdrant documentation: Filtering
5. Qdrant documentation: Hybrid queries
6. Qdrant documentation: Create a cluster (providers, free tier, Hybrid Cloud)
7. Weaviate documentation: Hybrid search
8. Weaviate documentation: Vector index types
9. Weaviate Cloud pricing and deployment options
10. Milvus documentation: Overview
11. Pinecone documentation: Database architecture
12. Pinecone documentation: Create an index (clouds, regions, sparse and hybrid)
13. OpenSearch documentation: Methods and engines
14. OpenSearch documentation: Efficient k-NN filtering
15. Elasticsearch documentation: Dense vector search
16. Elasticsearch documentation: kNN query (filter as pre-filter)
17. GitHub releases: Qdrant, Weaviate, Milvus, OpenSearch, pgvectorscale (versions as of 1 October 2026)