> pgvector, Qdrant, Weaviate, Milvus, Pinecone, OpenSearch vagy Elasticsearch? Gyakorlati útmutató 2026-ra: szűrés, hibrid keresés, skálázás, költség és EU-s hosztolás. > > Web page: https://balazscsorba.com/hu/blog/pgvector-vs-vector-databases · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/pgvector-vs-vector-databases.md) · [Deutsch](https://balazscsorba.com/de/blog/pgvector-vs-vector-databases.md) > Author: Balázs Csorba · Published: 2026-10-02 · Keywords: pgvector vs vector database, pgvector vs Qdrant, pgvector vs Pinecone, best vector database 2026, pgvector HNSW iterative scan, pgvector halfvec, OpenSearch vs Elasticsearch vector search, vector database EU hosting, hybrid search Postgres, Weaviate vs Milvus [Blog](https://balazscsorba.com/hu/blog)/RAG és keresés # pgvector vagy vektoradatbázis? Így válassz vektortárolót 2026-ban pgvector, Qdrant, Weaviate, Milvus, Pinecone, OpenSearch vagy Elasticsearch? Gyakorlati útmutató 2026-ra: szűrés, hibrid keresés, skálázás, költség és EU-s hosztolás. [Balázs Csorba](https://balazscsorba.com/hu/about)·2026\. október 2.·13 perc olvasás - pgvector - Vector databases - RAG - Hybrid search - EU hosting ![Ábra: döntési út az adataidtól a Postgres-beli pgvectorig, a vektormezős keresőmotorig vagy a dedikált vektoradatbázisig.](https://balazscsorba.com/images/blog/pgvector-vs-vector-databases/cover.webp?v=df702aff6b) ## A lényeg röviden - Ott kezdj, ahol az adataid már vannak: ha a rekordjaid Postgresben élnek, a pgvector HNSW-vel, halfvec-kel és iteratív szkennelésekkel a legtöbb RAG-terhelést lefedi, második rendszer üzemeltetése nélkül. - A szűrés többet számít a nyers sebességnél. Teszteld a valódi szűrőidet, mert egy közelítő indexszkennelés után alkalmazott szűrő túl kevés találatot adhat. - A memória az a skálázási küszöb, amit ki tudsz számolni: egy 1536 dimenziós float32 vektor 6144 bájt az indexköltség előtt, a halfvec ezt felezi. - Ha már üzemeltetsz OpenSearch-öt vagy Elasticsearch-öt kulcsszavas kereséshez, a vektormezők hozzáadása gyakran olcsóbb, mint új adatbázist bevezetni. - Dedikált vektoradatbázist akkor válassz, ha a vektorok maga a termék: nagyon nagy korpusz, sok bérlő vagy a keresést saját csapat viszi. Aláírás előtt ellenőrizd az EU-s régiókat és az üzemeltetést. Ezen az oldalon 1. [A rövid válasz](https://balazscsorba.com/#short-answer) 2. [Mit tud ma a pgvector](https://balazscsorba.com/#pgvector-today) 3. [A szűrésen dőlnek el a döntések](https://balazscsorba.com/#filtering) 4. [Hibrid keresés: beépítve vagy magad építve](https://balazscsorba.com/#hybrid-search) 5. [Egy döntési ábra](https://balazscsorba.com/#decision-diagram) 6. [A lehetőségek egymás mellett](https://balazscsorba.com/#comparison) 7. [Skálázási küszöbök és költség](https://balazscsorba.com/#scale-and-cost) 8. [EU-s hosztolás és adatvédelem](https://balazscsorba.com/#eu-hosting) 9. [Üzemeltetési teher](https://balazscsorba.com/#operations) 10. [Ellenőrzőlista döntés előtt](https://balazscsorba.com/#checklist) 11. [Én mit tennék](https://balazscsorba.com/#what-i-would-do) 12. [Források](https://balazscsorba.com/#sources) 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. **Az alapértelmezett sorrendem** Első választás: pgvector, ha a forrásadatok Postgresben vannak és a vektorok elférnek a memóriában. Második: OpenSearch vagy Elasticsearch, ha a kulcsszavas keresés, a facetek és a logok már ott vannak. Harmadik: dedikált vektoradatbázis, ha a vektorok, a szűrés vagy a többbérlős működés a termék szíve. 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](https://balazscsorba.com/hu/blog/rag-pipeline-chunking-hybrid-search-reranking): 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](https://github.com/pgvector/pgvector/blob/master/CHANGELOG.md) 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](https://github.com/pgvector/pgvector/blob/master/README.md) 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](https://github.com/timescale/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](https://qdrant.tech/documentation/concepts/filtering/) 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](https://docs.opensearch.org/latest/vector-search/filter-search-knn/efficient-knn-filtering/) 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](https://balazscsorba.com/hu/blog/llm-evals-for-product-features) 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](https://balazscsorba.com/hu/blog/rag-2026-hybrid-agentic-long-context) 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](https://qdrant.tech/documentation/concepts/hybrid-queries/), 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. Sorban kérdezz, és az első igennél állj meg. A cél az, hogy ne adj hozzá újabb rendszert, nem az, hogy ne válassz. 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. Lehetőség Legerősebb ebben Szűrés Hibrid keresés Mire figyelj **pgvector** Vektorok a relációs adatok mellett, egy rendszer WHERE plusz iteratív szkennelés, részleges indexek, partíciók Teljes szöveges keresés plusz saját fúzió SQL-ben Indexmemória, versenyez az OLTP-vel, indexelési dimenziókorlátok **Qdrant** Szűrésigényes keresés, rugalmas hibrid lekérdezések Payload indexek, beágyazott logikai feltételek Sparse és dense, RRF, DBSF, prefetch Második rendszer, amit szinkronizálni és védeni kell **Weaviate** Beépített hibrid keresés, többbérlős működés Szűrt vektorkeresés; a részleteket nem ellenőriztem, teszteld a sajátodat BM25 plusz vektor, alapértelmezetten relative score fusion A felhőben az ár a vektordimenziókkal skálázódik **Milvus** Nagyon nagy, elosztott terhelések Metaadat-szűrők; a részleteket nem ellenőriztem, teszteld a sajátodat Több sűrű és sparse vektormező Az elosztott üzemeltetés Kubernetesen valódi üzemeltetési munka **Pinecone** Menedzselt, serverless, nincs szerver Metaadat-szűrők a lekérdezés-végrehajtókban Sparse vektorok, hibrid, BM25 teljes szöveg Az általam olvasott dokumentációban csak serverless, a régió létrehozáskor rögzül **OpenSearch** Egy motor kulcsszóra, facetekre és vektorokra Szűrés a Faiss vagy Lucene gráfbejárás közben BM25 és vektorok egy indexben Klaszterhangolás, JVM és shard-tervezés **Elasticsearch** Ugyanaz, Elastic-eszközökkel és BBQ-kvantálással Előszűrő a közelítő kNN közben BM25 és kNN egy indexben Klaszterméretezés és üzemeltetés 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](https://balazscsorba.com/hu/blog/llm-cost-latency-prompt-caching-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](https://balazscsorba.com/hu/blog/gdpr-llm-api-eu-data-residency) 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](https://balazscsorba.com/hu/expertise/ai-engineer). ## Források 1. [pgvector README (index limits, HNSW defaults, iterative scans, filtering, halfvec)](https://github.com/pgvector/pgvector/blob/master/README.md) 2. [pgvector CHANGELOG (0.4.0 to 0.8.7)](https://github.com/pgvector/pgvector/blob/master/CHANGELOG.md) 3. [pgvectorscale: StreamingDiskANN, statistical binary quantization, filtered search](https://github.com/timescale/pgvectorscale) 4. [Qdrant documentation: Filtering](https://qdrant.tech/documentation/concepts/filtering/) 5. [Qdrant documentation: Hybrid queries](https://qdrant.tech/documentation/concepts/hybrid-queries/) 6. [Qdrant documentation: Create a cluster (providers, free tier, Hybrid Cloud)](https://qdrant.tech/documentation/cloud/create-cluster/) 7. [Weaviate documentation: Hybrid search](https://docs.weaviate.io/weaviate/concepts/search/hybrid-search) 8. [Weaviate documentation: Vector index types](https://docs.weaviate.io/weaviate/concepts/vector-index) 9. [Weaviate Cloud pricing and deployment options](https://weaviate.io/pricing) 10. [Milvus documentation: Overview](https://milvus.io/docs/overview.md) 11. [Pinecone documentation: Database architecture](https://docs.pinecone.io/guides/get-started/database-architecture) 12. [Pinecone documentation: Create an index (clouds, regions, sparse and hybrid)](https://docs.pinecone.io/guides/index-data/create-an-index) 13. [OpenSearch documentation: Methods and engines](https://docs.opensearch.org/latest/mappings/supported-field-types/knn-methods-engines/) 14. [OpenSearch documentation: Efficient k-NN filtering](https://docs.opensearch.org/latest/vector-search/filter-search-knn/efficient-knn-filtering/) 15. [Elasticsearch documentation: Dense vector search](https://www.elastic.co/docs/solutions/search/vector/dense-vector) 16. [Elasticsearch documentation: kNN query (filter as pre-filter)](https://www.elastic.co/docs/reference/query-languages/query-dsl/query-dsl-knn-query) 17. [GitHub releases: Qdrant, Weaviate, Milvus, OpenSearch, pgvectorscale (versions as of 1 October 2026)](https://github.com/qdrant/qdrant/releases) ## Gyakori kérdések Elég a pgvector éles RAG-hoz? Sok terhelésnél igen. A pgvector támogatja a HNSW és IVFFlat indexeket, a halfvec és sparsevec típusokat, a 0.8.0 verzió óta pedig az iteratív indexszkenneléseket szűrt lekérdezésekhez. Ha az adataid már Postgresben vannak és az index elfér a memóriában, ez megbízható alapértelmezés. Döntés előtt terheld meg a saját szűrőiddel és adataiddal. Mikor használjak dedikált vektoradatbázist a pgvector helyett? Amikor a vektorterhelés túlnő azon, amit a tranzakciós adataid mellett üzemeltetni akarsz: nagyon nagy korpusz, erős szűrés sok bérlőn át, speciális indextípusok, vagy olyan csapat, amely a keresést külön termékként kezeli. Ilyenkor a Qdrant, Weaviate, Milvus vagy Pinecone célzott funkciókat és független skálázást ad. Mik az iteratív indexszkennelések a pgvectorban? Az iteratív szkennelések, amelyeket a pgvector 0.8.0 hozott, lehetővé teszik, hogy egy közelítő index addig szkenneljen tovább, amíg elég sor teljesíti a WHERE szűrőt. Nélkülük a HNSW lekérdezés nagyjából hnsw.ef\_search jelöltet (alapértelmezés 40) néz meg és utána szűr, így egy szelektív szűrő a kértnél kevesebb sort adhat. A hnsw.iterative\_scan beállítással kapcsolhatod be. Lehet hibrid keresést csinálni Postgresben? Igen. A pgvector kombinálható a PostgreSQL teljes szöveges keresésével, a két rangsort pedig Reciprocal Rank Fusionnel egyesítheted SQL-ben, vagy cross-encoderrel újrarangsorolhatod. A dedikált rendszerek, mint a Qdrant, Weaviate és Milvus, beépített funkcióként adják a hibrid lekérdezést, így nem neked kell megírnod a fúziót. Hogyan tartom az EU-ban a vektoradatokat? Válassz EU-régiós menedzselt szolgáltatást, vagy hosztolj magad EU-s adatközpontban. A Pinecone AWS Frankfurtot és Írországot, valamint GCP Hollandiát sorol fel, a Weaviate Cloud támogat EU-régiókat. A régiót létrehozáskor rögzítsd, mert a Pinecone dokumentációja szerint utólag nem módosítható, és ellenőrizd azt is, hol fut az embedding modelled. Kell vektoradatbázis egy kis RAG-alkalmazáshoz? Általában nem. Néhány százezer chunk kényelmesen elfér Postgresben pgvectorral, sőt egy folyamaton belüli indexben is. Kezdj a legegyszerűbb tárolóval, amely támogatja a szűrőidet, mérd a keresési minőséget értékelő készlettel, és csak akkor költözz, ha egy mért korlát rákényszerít. Írta: Csorba Balázs Senior fullstack és AI mérnök Stájerországban – több mint 10 év Vue, Nuxt, Node.js és PHP, ma AI-ügynököknek építek eszközöket. [AI fejlesztés és MCP szerverek →](https://balazscsorba.com/hu/expertise/ai-engineer)[Rólam →](https://balazscsorba.com/hu/about) ## További cikkek - [LLM-hallucinációk csökkentése éles rendszerben: grounding, hivatkozások és a nemet mondás tudománya](https://balazscsorba.com/hu/blog/llm-hallucination-grounding-citations) - [GraphRAG és knowledge-graph RAG: mikor veri a gráf a vektoros keresést](https://balazscsorba.com/hu/blog/graphrag-knowledge-graph-rag) - [RAG kiértékelése: retrieval metrikák, faithfulness, és hogyan derül ki, melyik fele hibázott](https://balazscsorba.com/hu/blog/rag-evaluation-metrics) - [Szemantikus termékkeresés B2B webshopokban: cikkszámok, hibrid keresés és amit mérned kell](https://balazscsorba.com/hu/blog/semantic-product-search-b2b) ## Pont erre van szükséged? Írj a projektedről vagy a pozícióról – szívesen hallok felőled. [Beszélgetés kérése](mailto:contact@balazscsorba.com) [Kapcsolódjunk LinkedInen](https://www.linkedin.com/in/balazs-csorba)