[{"data":1,"prerenderedAt":699},["ShallowReactive",2],{"tool-pgvector-hu":3},{"slug":4,"published":5,"minutes":6,"category":7,"tags":8,"keywords":14,"about":21,"sources":27,"cover":42,"og":43,"expertise":44,"locales":45,"lang":48,"title":49,"description":50,"coverAlt":51,"url":23,"pricing":52,"kind":53,"metaTitle":54,"takeaways":55,"faq":61,"toc":74,"blocks":99,"others":494},"pgvector","2026-09-21",10,"rag",[9,10,11,12,13],"Vector search","Postgres","HNSW","RAG","Quantisation",[4,15,16,17,18,19,20],"pgvector vs qdrant","postgres vector search","hnsw index postgres","iterative index scans","binary quantization postgres","vector database postgres",[22,24],{"name":4,"url":23},"https:\u002F\u002Fgithub.com\u002Fpgvector\u002Fpgvector",{"name":25,"url":26},"PostgreSQL","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FPostgreSQL",[28,30,33,36,39],{"title":29,"url":23},"pgvector README",{"title":31,"url":32},"pgvector changelog","https:\u002F\u002Fgithub.com\u002Fpgvector\u002Fpgvector\u002Fblob\u002Fmaster\u002FCHANGELOG.md",{"title":34,"url":35},"PostgreSQL news: pgvector 0.8.2 released","https:\u002F\u002Fwww.postgresql.org\u002Fabout\u002Fnews\u002Fpgvector-082-released-3245\u002F",{"title":37,"url":38},"AWS: Scale pgvector with binary quantization","https:\u002F\u002Faws.amazon.com\u002Fblogs\u002Fdatabase\u002Fscale-pgvector-with-binary-quantization-on-amazon-aurora-postgresql\u002F",{"title":40,"url":41},"pgvector licence","https:\u002F\u002Fgithub.com\u002Fpgvector\u002Fpgvector\u002Fblob\u002Fmaster\u002FLICENSE","\u002Fimages\u002Fblog\u002Fpgvector\u002Fcover.webp","\u002Fimages\u002Fblog\u002Fpgvector\u002Fog.jpg","ai-engineer",[46,47,48],"en","de","hu","pgvector, értékelés: az a vektordatázis, amelyet nem kell üzemeltetned","Értékelés a pgvector 0.8.7-ről: iteratív indexszkennelés szűrt kereséshez, HNSW és IVFFlat, bináris kvantizálás 100 millió vektornál, és a CVE, amely az indexépítést javítási tétellé tette.","A lekérdezés felül három útra bontakozik: pontos szekvenciális szkennelés, HNSW gráfjárás és IVFFlat vizsgálat; alul egy iteratív szkennelés folytatódik, amíg a limit kitelik.","PostgreSQL licence","Vector database extension","pgvector: vektorkeresés Postgresben · Balázs Csorba",[56,57,58,59,60],"A pgvector a PostgreSQL licenc alatt álló bővítmény, így a vektorok sima táblákban laknak, az ügyfélszűrők, JOIN-ek és kaszkádos törlések pedig tranzakciók maradnak.","Az iteratív indexszkennelés, ami 0.8.0 óta létezik, a szűrt keresés megoldása: nélküle a sorok 10%-át eltaláló szűrő alapértelmezett ef_search 40 mellett körülbelül négy sort ad vissza.","A AWS 367 GB-os HNSW-indexet mért 100 millió 768 dimenziós vektornál, szemben egy 38 GB-os, binárisan kvantizált indexszel, amely 1,1 óra alatt épült meg 16,1 helyett.","A CVE-2026-3172, amelyet 2026 februárjában a 0.8.2 javított, puffer-túlcsordulás volt a párhuzamos HNSW-indexépítésben, amely más relációk adatait szivárogtathatta ki; a javításhoz nem kell újraindexelés.","A korlát a memória, nem az API: ha az index nem fér már a shared_buffers-be, a válaszok a halfvec, a bináris kvantizálás, a particionálás vagy egy második rendszer.",[62,65,68,71],{"q":63,"a":64},"Ingyenes a pgvector használata?","Igen. A PostgreSQL licenc alatt jelenik meg, díj, open-core szétválasztás és fizetős terv nélkül, és egyre több hosztolt Postgres-szolgáltatónál előre telepítve érkezik. A lényeg a verzió: az iteratív indexszkenneléshez 0.8.0 vagy újabb kell.",{"q":66,"a":67},"Mikor érdemes HNSW-t használni IVFFlat helyett?","A HNSW jobb sebesség-találati arányt ad, üres táblán is létrehozható, mert nincs edzési lépése, viszont lassabban épül és több memóriát igényel. Az IVFFlat gyorsabban épül, de előbb adat kell hozzá; a README szerint lists = rows \u002F 1000 egymillió sorig, afölé sqrt(rows), a probes pedig sqrt(lists)-zel kezdve.",{"q":69,"a":70},"Működik a pgvector WHERE feltétellel?","Igen, de közelítő indexnél a szűrő az indexszkennelés után fut, így egy szelektív feltétel kevesebb sort adhat vissza, mint amennyit a LIMIT kér. A dokumentált megoldások: B-tree a szűrőoszlopon, iteratív indexszkennelés a hnsw.iterative_scan kapcsolóval, részleges index értékenként és listaparticionálás sok különböző értékhez.",{"q":72,"a":73},"Hány vektort kezel a pgvector?","Egyetlen táblát a PostgreSQL 32 TB-os relációkorlátja és az határoz meg, mennyi fér a memóriába; a AWS 367 GB indexet mért 100 millió 768 dimenziós vektornál, és milliárdos nagyságrenden particionálást javasol. Efölött a README replikákat, Citust, PgDogot vagy listaparticionálást ajánl beépített shard-réteg helyett.",[75,78,81,84,87,90,93,96],{"id":76,"title":77},"what-it-is","Mi ez",{"id":79,"title":80},"how-it-works","Hogyan működik",{"id":82,"title":83},"filtered-search","Szűrt keresés",{"id":85,"title":86},"getting-started","Első lépések",{"id":88,"title":89},"performance","Teljesítmény",{"id":91,"title":92},"where-it-shingles","Ahol megakad",{"id":94,"title":95},"verdict","Ítélet",{"id":97,"title":98},"sources","Források",[100,104,107,110,113,186,187,198,207,218,219,222,257,272,273,276,278,285,299,300,303,355,358,364,390,391,394,438,444,445,448,464,470,471],{"type":101,"content":102},"paragraph",[103],"A pgvector egy PostgreSQL-bővítmény, amely vektorokat egy sima tárolóba tesz, és SQL-lel keres azokban. Nem egy rácsavarozott lekérdezésnyelvű vektordatbázis: négy oszloptípust, hat távolságoperátort és két indextípust ad ahhoz a adatbázishoz, amelyet a legtöbb csapat amúgy is üzemeltet, a PostgreSQL licenc alatt, amely a lehető legmegengedőbb. Az itt képviselt álláspont: ez a helyes alapértelmezés szinte minden, legfeljebb néhány tízmillió vektorig terjedő előkeresési feladathoz, és aki ekkora méretnél külön vektordatázist épít, nem képességet vesz, hanem üzemeltetési terhet.",{"type":101,"content":105},[106],"A Qdranttal, a Weavitate-val, a Chromával és a teljesen felhőben üzemeltetett vektor szolgáltatásokkal versengez, valamint minden olyan hosztolt Postgresszel, amely ma már alapból szállítja a bővítményt. Ami megszűnik, az egy teljes infrastruktúra-kategória: nincs második szolgáltatás, nincs második kommunikációs protokoll hitelesítésre, nincs második mentési ütemezés, nincs eltérés a sorok és azokat leíró beágyazások között. Ami megmarad, az a Postgres minden korlátja: egy csomópont memóriája, egy csomópont vacuumja, egy csomópont írási teljesítménye. És ezek válnak a tervezési paraméterekké abban a pillanatban, amikor az index már nem fér a RAM-ba.",{"type":108,"level":109,"id":76,"text":77},"heading",2,{"type":101,"content":111},[112],"Az első kiadás, a 0.1.0, 2021. április 20-án jelent meg, a jelenlegi kiadás pedig a 2026. október 1-i 0.8.7; a repository ellenőrzéskor 23.300 csillagot és 1.300 forkot mutatott. A PostgreSQL 13 és újabb verzióit támogatja, Docker-imageként, PGXN-en, APT-n, Yumon, Homebrew-en és conda-forge-on át kapható, és egyre több hosztolt szolgáltatónál előre telepítve érkezik. Ez azért számít, mert a régi verzión ragadt felhős szolgáltatás a leggyakoribb oka annak, hogy egy csapat úgy hiszi, megvan egy biztonsági javítása, ami nincs meg.",{"type":114,"ordered":115,"items":116},"list",false,[117,124,130,149,158,184],[118,119,123],"Licenc: ",{"tag":120,"children":121},"strong",[122],"a PostgreSQL licenc",", ugyanaz a megengedő szöveg, amelyet maga a PostgreSQL használ. Nincs open core, nincs kereskedelmi szint, nincs fizetős terv mögé rejtett funkció.",[125,126,129],"A 0.8.7-es kiadás 2026. október 1-jén; a 0.8-as széria ",{"tag":120,"children":127},[128],"iteratív indexszkennelést"," ad 2024 októbere, a 0.8.0 óta, és ez a funkció tette kiszámíthatóvá a szűrt keresést.",[131,132,136,137,140,141,144,145,148],"Négy típus: ",{"tag":133,"children":134},"code",[135],"vector"," dimenciónként 4 bájttal, ",{"tag":133,"children":138},[139],"halfvec"," 2-vel, ",{"tag":133,"children":142},[143],"bit"," dimenciónként egy bittel, és ",{"tag":133,"children":146},[147],"sparsevec"," ritka vektorokhoz legfeljebb 1000 nem-nulla elemmel.",[150,151,153,154,157],"Két indextípus: ",{"tag":120,"children":152},[11]," a legjobb sebesség-találati arányért, edzési lépés nélkül, ",{"tag":120,"children":155},[156],"IVFFlat"," gyorsabb építéshez és kisebb memóriaigényhez.",[159,160,163,164,167,168,171,172,175,176,179,180,183],"Hat operátor, közvetlenül az ORDER BY-ban: L2 (",{"tag":133,"children":161},[162],"\u003C->","), belső szorzat (",{"tag":133,"children":165},[166],"\u003C#>","), koszinusz (",{"tag":133,"children":169},[170],"\u003C=>","), L1 (",{"tag":133,"children":173},[174],"\u003C+>","), Hamming (",{"tag":133,"children":177},[178],"\u003C~>",") és Jaccard (",{"tag":133,"children":181},[182],"\u003C%>",").",[185],"A tárolás és a hozzáférés magától a Postgrestől jön: ACID, WAL-alapú replikáció, pillanatnyi visszaállítás, JOIN-ek és soronkénti biztonság ugyanabban a táblában, mint a beágyazások.",{"type":108,"level":109,"id":79,"text":80},{"type":101,"content":188},[189,190,193,194,197],"Index nélkül a vektor-lekérdezés szekvenciális szkennelés, távolságfüggvényre rendezett ORDER BY-jal: pontos eredmény, tökéletes találati arány, és a tábla méretével növekvő költség. Ezt a játszmát egy közelítő index megváltoztatja. A HNSW többrétegű grágot épít a vektorok fölé, és azon jár kicsit gyengébb találati arányért cserébe, a költség viszont többé nem nő a táblával; az IVFFlat vektorokat listákba rendez, és csak egy részüket vizsgálja. A mindent eldöntő részlet, hogy a lekérdezéstervező csak akkor nyúl az indexhez, ha a lekérdezés így néz ki: ",{"tag":133,"children":191},[192],"ORDER BY embedding \u003C=> $1 LIMIT n",". Ugyanez ",{"tag":133,"children":195},[196],"ORDER BY 1 - (embedding \u003C=> $1) DESC"," alakban a README szerint nem használ indexet.",{"type":199,"attrs":200,"inner":204,"caption":205},"diagram",{"viewBox":201,"role":202,"aria-labelledby":203},"0 0 720 376","img","pgv-t pgv-d","\u003Ctitle id=\"pgv-t\">Három végrehajtási út egyetlen vektor-lekérdezéshez\u003C\u002Ftitle>\u003Cdesc id=\"pgv-d\">A távolságoperátoros ORDER BY-t és LIMIT-et hordozó lekérdezés felül három útra bontakozik. Balra, nincs index: szekvenciális szkennelés tökéletes találati aránnyal, aminek a költsége soronként nő. Középen, HNSW: járás egy többrétegű gráfon, alapértelmezett m = 16 és ef_search = 40 mellett, ahol a WHERE feltétel csak az indexszkennelés jelöltjei után fut. Jobbra, IVFFlat: vektorok listákba rendezve, csak a legközelebbi listák vizsgálva, az adatok betöltése után építve, az ivfflat.probes állítva, gyengébb sebesség-találati arány mellett. Alul egy sáv: az iteratív indexszkennelés, ami 0.8.0 óta addig fut, amíg a szűrő sorokat ejt, strict_order vagy relaxed_order módban, a hnsw.max_scan_tuples által korlátozva, alapértelmezett 20.000.\u003C\u002Fdesc>\u003Ctext x=\"20\" y=\"26\" class=\"d-title\">One query, three execution paths\u003C\u002Ftext>\u003Ctext x=\"700\" y=\"26\" text-anchor=\"end\" class=\"d-label\">the ORDER BY decides\u003C\u002Ftext>\u003Crect x=\"260\" y=\"44\" width=\"200\" height=\"50\" rx=\"10\" class=\"d-accent\"\u002F>\u003Ctext x=\"360\" y=\"66\" text-anchor=\"middle\" class=\"d-text\">Query\u003C\u002Ftext>\u003Ctext x=\"360\" y=\"84\" text-anchor=\"middle\" class=\"d-small\">ORDER BY distance, LIMIT 10\u003C\u002Ftext>\u003Cpath d=\"M360 94 V112\" class=\"d-line\"\u002F>\u003Cpath d=\"M126 112 H594\" class=\"d-line\"\u002F>\u003Cpath d=\"M126 112 V124\" class=\"d-line\"\u002F>\u003Cpath d=\"M360 112 V124\" class=\"d-line\"\u002F>\u003Cpath d=\"M594 112 V124\" class=\"d-line\"\u002F>\u003Crect x=\"20\" y=\"124\" width=\"213\" height=\"140\" rx=\"10\" class=\"d-box\"\u002F>\u003Ctext x=\"126\" y=\"154\" text-anchor=\"middle\" class=\"d-text\">Exact scan\u003C\u002Ftext>\u003Ctext x=\"126\" y=\"182\" text-anchor=\"middle\" class=\"d-small\">sequential scan\u003C\u002Ftext>\u003Ctext x=\"126\" y=\"206\" text-anchor=\"middle\" class=\"d-small\">perfect recall\u003C\u002Ftext>\u003Ctext x=\"126\" y=\"230\" text-anchor=\"middle\" class=\"d-small\">cost grows per row\u003C\u002Ftext>\u003Ctext x=\"126\" y=\"254\" text-anchor=\"middle\" class=\"d-small\">no index needed\u003C\u002Ftext>\u003Crect x=\"253\" y=\"124\" width=\"214\" height=\"140\" rx=\"10\" class=\"d-sky\"\u002F>\u003Ctext x=\"360\" y=\"154\" text-anchor=\"middle\" class=\"d-text\">HNSW\u003C\u002Ftext>\u003Ctext x=\"360\" y=\"182\" text-anchor=\"middle\" class=\"d-small\">multilayer graph walk\u003C\u002Ftext>\u003Ctext x=\"360\" y=\"206\" text-anchor=\"middle\" class=\"d-small\">m = 16, ef_search = 40\u003C\u002Ftext>\u003Ctext x=\"360\" y=\"230\" text-anchor=\"middle\" class=\"d-small\">filter runs after the scan\u003C\u002Ftext>\u003Ctext x=\"360\" y=\"254\" text-anchor=\"middle\" class=\"d-small\">the default index\u003C\u002Ftext>\u003Crect x=\"486\" y=\"124\" width=\"213\" height=\"140\" rx=\"10\" class=\"d-gold\"\u002F>\u003Ctext x=\"592\" y=\"154\" text-anchor=\"middle\" class=\"d-text\">IVFFlat\u003C\u002Ftext>\u003Ctext x=\"592\" y=\"182\" text-anchor=\"middle\" class=\"d-small\">lists, then probes\u003C\u002Ftext>\u003Ctext x=\"592\" y=\"206\" text-anchor=\"middle\" class=\"d-small\">build it after the load\u003C\u002Ftext>\u003Ctext x=\"592\" y=\"230\" text-anchor=\"middle\" class=\"d-small\">tune ivfflat.probes\u003C\u002Ftext>\u003Ctext x=\"592\" y=\"254\" text-anchor=\"middle\" class=\"d-small\">faster build, less recall\u003C\u002Ftext>\u003Crect x=\"20\" y=\"284\" width=\"679\" height=\"76\" rx=\"10\" class=\"d-box d-dash\"\u002F>\u003Ctext x=\"40\" y=\"312\" class=\"d-text\">Iterative scan, added in 0.8.0\u003C\u002Ftext>\u003Ctext x=\"40\" y=\"336\" class=\"d-small\">the scan continues when the filter drops rows: strict_order keeps exact distance order\u003C\u002Ftext>\u003Ctext x=\"40\" y=\"356\" class=\"d-small\">relaxed_order trades order for recall; bounded by hnsw.max_scan_tuples, default 20,000\u003C\u002Ftext>",[206],"A szűrő csak a közelítő index munkája után fut, ezért vitatkozik egymással a szelektív WHERE és az approximatív index, amíg a szkennelésnek nem szabad továbbmennie.",{"type":101,"content":208},[209,210,213,214,217],"A második részlet, hogy hol fut a ",{"tag":133,"children":211},[212],"WHERE"," feltétel. A közelítő index jelölteket állít elő, a szűrő pedig csak utána fut rajtuk, így a szelektivitás és a találati arány összefonódik: az alapértelmezett ",{"tag":133,"children":215},[216],"hnsw.ef_search"," 40-es értékénél és egy a sorok 10%-át eltaláló feltétnél körülbelül négy sor jön vissza. Semmi nem hibás, az index egyszerűen sosem látta az ejtett sorokat. Ez a viselkedés a leggyakoribb oka annak, hogy valaki kevesebb találatot jelez vissza, és erre létezik dokumentált megoldás, nem pedig kerülőút.",{"type":108,"level":109,"id":82,"text":83},{"type":101,"content":220},[221],"A szűrés itt nem utólagos gondolat, hanem elsőrendű probléma, és a dokumentáció négy lépést vesz végig abban a sorrendben, amelyben egy áttekintő kipróbálná őket. Hogy melyik érvényes, attól függ, mennyire szelektív a szűrő, mennyi találati arányra van valójában szükség, és hány különböző értéket vesz fel a szűrő: egy 50.000 értékes ügyfél-azonosító máshogy viselkedik, mint egy nyolc értékes országkód.",{"type":114,"ordered":115,"items":223},[224,231,241,255],[225,226,229,230],"Először a szűrő oszlopára sima ",{"tag":120,"children":227},[228],"B-tree"," index kerüljön",". Ha a feltétel a sorok kis hányadát éri el, ez pontos legközelebbi szomszédokat ad közelítő index érintése nélkül, és a README épp ezt nevezi kiindulópontnak.",[232,233,236,237,240],"Ha a szűrő széles marad, kapcsoljuk be az iteratív indexszkennelést a ",{"tag":133,"children":234},[235],"SET hnsw.iterative_scan = relaxed_order"," paranccsal: a gráf addig jár, amíg a LIMIT betelik, és ",{"tag":133,"children":238},[239],"strict_order"," akkor jön, amikor a távolsági sorrendnek pontosnak kell lennie.",[242,243,246,247,250,251,254],"Korlátozzuk a munkát. A ",{"tag":133,"children":244},[245],"hnsw.max_scan_tuples"," alapértelmezett értéke 20.000, a ",{"tag":133,"children":248},[249],"hnsw.scan_mem_multiplier"," pedig a ",{"tag":133,"children":252},[253],"work_mem"," egy szorzója, így a szelektív szűrő véges szkenneléssé romlik, nem végtelenné.",[256],"Sok különböző értéknél részleges index kell értékenként, vagy listaparticionálni kell a táblát. A README azt is megjegyzi, hogy az egy közelítő indexet megosztó ügyfelek egymás találati arányát is befolyásolják, ez tehát partitionálási, nem hangolási érv.",{"type":258,"variant":259,"title":260,"body":261},"callout","note","A találati arány az a mérőszám, amit senki nem mér",[262],[263,264,267,268,271],"A dokumentáció saját módszere ugyanazt a lekérdezést egy tranzakción belül futtatni ",{"tag":133,"children":265},[266],"enable_indexscan = off"," mellett, és a közelítő eredménnyel összehasonlítani. A csapatok a késleltetésre hangolják az ",{"tag":133,"children":269},[270],"ef_search"," értéket, az összehasonlítást pedig kihagyják, és épp így lesz a tíz sorból négyet visszaadó index gyorsnak kikiáltva.",{"type":108,"level":109,"id":85,"text":86},{"type":101,"content":274},[275],"A teljes felület SQL, és ez az oka annak, hogy egy saját API-val dolgozó rendszer helyett ezt érdemes választani. Az alábbi kódrészlet egy éles tábla formája: rögzített dimenziójú oszlop, pontos index a szűrőre, közelítő index a vektorra, és az az egy beállítás, amely eldönti, hogy a szűrt lekérdezés röviden tér-e vissza.",{"type":133,"code":277},"CREATE EXTENSION IF NOT EXISTS vector;\n\n-- The dimension is part of the type, so every row has to match it.\nCREATE TABLE chunks (\n  id         bigserial PRIMARY KEY,\n  tenant_id  text       NOT NULL,\n  embedding  vector(1536)\n);\n\n-- Exact index on the filter first: for a selective tenant it answers the\n-- whole query and the approximate index is never consulted.\nCREATE INDEX ON chunks (tenant_id);\n\n-- Bulk load with COPY, then build the approximate index on top of the data.\nCREATE INDEX ON chunks USING hnsw (embedding vector_cosine_ops)\n  WITH (m = 16, ef_construction = 64);\n\n-- A filter matching 10% of rows with ef_search = 40 returns about four rows,\n-- so the scan has to be allowed to continue past its first pass.\nSET hnsw.iterative_scan = relaxed_order;\nSET hnsw.ef_search = 100;\n\nSELECT id\nFROM chunks\nWHERE tenant_id = 'acme'\nORDER BY embedding \u003C=> (SELECT embedding FROM chunks WHERE id = 42)\nLIMIT 10;",{"type":101,"content":279},[280,281,284],"Három döntés érdemes a védelmére az alábbi kódban. A dimenzió a típus része, így egy másik beágyazó modell által írt sor már az ",{"tag":133,"children":282},[283],"INSERT"," nél bukik, nem a lekérdezés idején. A közelítő index az adatok után épül, mert egy üres táblán létrehozott HNSW-gráfnak nincs mit összekötnie, és úgyis újraépítenék. A próbavektor pedig subselectből jön, abból a formából, amit a lekérdezéstervező elfogad; ugyanez a lekérdezés kifejezéssel az ORDER BY-ban figyelmeztetés nélkül szekvenciális szkennelésre esik vissza.",{"type":258,"variant":286,"title":287,"body":288},"warn","Frissíts, mielőtt indexet építesz",[289],[290,291,294,295,298],"A CVE-2026-3172, amelyet a 2026. február 25-i 0.8.2 javított, puffer-túlcsordulás volt a párhuzamos HNSW-indexépítésben, amely más relációk adatait szivárogtathatta ki, vagy a szervert összeomlaszthatta. A javítás egy bővítmény-frissítés, ",{"tag":133,"children":292},[293],"ALTER EXTENSION pgvector UPDATE",", újraindexelés nélkül; ameddig a frissítés nem lehetséges, a ",{"tag":133,"children":296},[297],"max_parallel_maintenance_workers = 0"," beállítása az építés idejére a dokumentált megoldás. Későbbi kiadások további puffer-túlcsordulásokat javítottak az IVFFlat-építésben, a 0.8.6-ban, majd a 2026. október 1-i 0.8.7-ben is. Érdemes elolvasni a felhős szolgáltatónál ténylegesen futó verziót, nem feltételezni.",{"type":108,"level":109,"id":88,"text":89},{"type":101,"content":301},[302],"A memória az egész teljesítmény-történet. Egy vektoroszlop dimenciónként 4 bájtot és 8 bájtos fejlécet foglal, így 1536 dimenzió index nélkül körülbelül 6 KB soronként, és a AWS mérése szerint egy 100 millió 768 dimenziós vektorral dolgozó teljes pontosságú HNSW-index 367 GB, nagyjából 3,7 GB milliónként. A többi típus pontosan ezért a számért lett kitalálva.",{"type":304,"head":305,"rows":314},"table",[306,308,310,312],[307],"Típus",[309],"Bájt dimenciónként",[311],"Indexelhető korlát",[313],"Mit jár érte",[315,325,335,345],[316,319,321,323],[317],{"tag":133,"children":318},[135],[320],"4",[322],"2.000 dim",[324],"az alap; a rajta végzett pontos keresés pontos találati arányt ad",[326,329,331,333],[327],{"tag":133,"children":328},[139],[330],"2",[332],"4.000 dim",[334],"feleakkora index, a AWS mérése szerint szinte nulla találati arány-veszteség",[336,339,341,343],[337],{"tag":133,"children":338},[143],[340],"1\u002F8",[342],"64.000 dim",[344],"Hamming a előjel-biteken, a találati arányhoz újrasorrendezés kell",[346,349,351,353],[347],{"tag":133,"children":348},[147],[350],"8 nem-nulla elemenként",[352],"1.000 nem-nulla",[354],"ritka beágyazások, L2, koszinusz, belső szorzat és L1",{"type":101,"content":356},[357],"A AWS a legtisztább nyilvános számokat közölte erről: VectorDBBench v0.3.4, top_k=100, Aurora PostgreSQL 18.4, pgvector 0.8.0. A 768 dimenziós LAION 100M esetén egy 128 GB-os r8g.4xlarge egy 367 GB-os, teljes pontosságú HNSW-indexet tárolt, amelyet nem tudott a gyorsítótárban tartani: 3,4 lekérdezés másodpercenként hidegen, 10 párhuzamos kapcsolat mellett, 3.336 melegen, 0,965 találati arány, 16,1 óra építés. Az újrasorrendező bináris kvantizálás 38 GB-ra és 1,1 órára vitte le az indexet, másodpercenként 13,5 hideg és 895 meleg lekérést ért el, és ezt a találati arány fizette meg: 0,931-re.",{"type":101,"content":359},[360,361,363],"Ugyanez a mérés hordozza az ellenpéldát is, ezért a számait a módszertanukkal együtt kell olvasni. A Cohere 10M esetén, ahol a 768 dimenziós beágyazások a nulla közel csoportosulnak, a bináris kvantizálás 3000 jelölt újrasorrendezésével ért csak 0,93 találati arányt, és másodpercenként 16 lekérdezésre esett vissza 1640 ms p99 mellett, míg egy 384 GB-os gépen a teljes pontosságú HNSW 6930 lekérést adott 0,952 találati aránnyal. A kvantizálás eloszlásfüggő: validálni kell a saját beágyazásokon, vagy ",{"tag":133,"children":362},[139]," használni, és felezni az indexet találgatás helyett.",{"type":114,"ordered":115,"items":365},[366,372,382,388],[367,368,371],"Az ",{"tag":133,"children":369},[370],"maintenance_work_mem"," értékét emelni kell HNSW-index építése előtt; a Postgres Notice-t ír, amikor a gráf már nem fér bele, és a README óva int attól, hogy a kiszolgáló memóriájáig emeljük.",[373,374,377,378,381],"Töltsünk ",{"tag":133,"children":375},[376],"COPY"," paranccsal, indexeljünk utána, és éles környezetben ",{"tag":133,"children":379},[380],"CREATE INDEX CONCURRENTLY"," használjunk, hogy az építés ne blokkolja az írásokat.",[383,384,387],"A HNSW-index VACUUM-ja eltarthat egy ideig; a dokumentált gyorsítás, hogy előbb ",{"tag":133,"children":385},[386],"REINDEX INDEX CONCURRENTLY",", utána vacuum.",[389],"A vízszintes skálázást kölcsönözzük, nem építjük: a replikáció és a pillanatnyi visszaállítás a WAL-ból jön, a shardoláshoz pedig a README a Citusra, a PgDogra vagy a listaparticionálásra mutat.",{"type":108,"level":109,"id":91,"text":92},{"type":101,"content":392},[393],"A gyengeségek strukturálisak, nem befejezetlenek. Minden egy Postgres-csomóponton fut, így az index, a heap és a gyorsítótár ugyanazért a memóriáért verseng, és amelyik index nem fér bele, az előbb I\u002FO-probléma lesz, csak utána találati arány-probléma. A közelítő keresés és a szelektív szűrők iteratív szkenneléssel is vitáznak, mert a véges szkennelés véges marad. A vacuum és az indexkarbantartás ennek az adatbázisnak a munkája, nem valaki másé. Beépített shardolás pedig nincs: a vízszintes skálázás replikákat, particionálást vagy egy bővítményt jelent.",{"type":304,"head":395,"rows":404},[396,398,400,402],[397],"Alternatíva",[399],"Üzemeltetési forma",[401],"Üzemeltetési teher",[403],"Hol jobb",[405,416,427],[406,410,412,414],[407],{"tag":120,"children":408},[409],"Qdrant",[411],"Külön Rust-szerver vagy a gyártó felhője",[413],"Még egy kluster javításra, mentésre, biztonságra",[415],"Payload-szűrés és kvantizálás nagy volumenű találati arányra hangolva",[417,421,423,425],[418],{"tag":120,"children":419},[420],"Weaviate",[422],"Külön szerver GraphQL API-val vagy a gyártó felhője",[424],"Ugyanez még egyszer, plusz saját modulkonfiguráció",[426],"Hibrid keresés és vektorosítás egy helyen konfigurálva",[428,432,434,436],[429],{"tag":120,"children":430},[431],"Chroma",[433],"Beágyazva a folyamatba vagy kis önálló szerverként",[435],"Szinte semmi, de Postgres sincs",[437],"A legrövidebb út a prototípustól a futó rendszerig",{"type":101,"content":439},[440,441,443],"A őszinte határ: a pgvector addig nyer, amíg a vektorok a csapat amúgy is tárolt adatainak egy oszlopa, és akkor veszít, amikor egy lekérdezésnek ugyanabban a memóriában kell tartania egy nagy gráfot, egy szűrt szkennelést és az alkalmazás munkakészletének többi részét. A AWS ezt a határt 100 millió vektornál 367 GB indexben mérte meg, és kvantizálással, valamint particionálással kerülte meg. Akik ezt a cserét nem akarják magukra vállalni, négy kijáratuk van: ",{"tag":133,"children":442},[139],", újrasorrendezéssel együtt futó bináris kvantizálás, ügyfél szerinti particionálás vagy egy külön rendszer, az első kettő pedig elég olcsó ahhoz, hogy a negyedikről való beszélgetés előtt ki kell próbálni.",{"type":108,"level":109,"id":94,"text":95},{"type":101,"content":446},[447],"A pgvector legyen az alapértelmezett válasz arra, hová kerüljenek a beágyazások, minden olyan csapatnál, amely már futtat Postgrest, és egy külön vektordatázisnak magának kell megindokolnia, miért kerüljön sorra. A bővítménynek van egy szokatlan tulajdonsága: a hibái azok a hibák, amiket a csapat már ismer egy adatbázisból — memónynyomás, karbantartási ablakok, egy csomópont írási teljesítménye. Mást csak akkor válassz, ha a méret vagy a késleltetési cél megnevezhető.",{"type":114,"ordered":449,"items":450},true,[451,453,455,457,462],[452],"Válaszd a pgvector-t, ha a vektorok olyan sorokat írnak le, amelyeket a csapat amúgy is tárol, és az ügyfélszigetelés, a kaszkádos törlés vagy a forrástáblával való JOIN tranzakciónak kell lennie.",[454],"Válaszd, ha az anyag legfeljebb néhány tízmillió vektorból áll, és a szűrő elég szelektív ahhoz, hogy a szűrőoszlopon lévő B-tree vigye a lekérdezés java részét.",[456],"Válaszd, ha az alternatíva egy második éles rendszer: a bővítmény örökli a már meglévő mentést, replikációt, megfigyelést és hozzáférés-kezelést, és nem ad hozzá új üzemeltetnivalót.",[458,459,461],"Ne válaszd, ha egyetlen lekérdezésnek több száz gigabájtos gráfot és az alkalmazás munkakészletét is a memóriában kell tartania, hacsak a ",{"tag":133,"children":460},[139]," vagy a bináris kvantizálás nincs már megmérve a valós beágyazásokon.",[463],"Ne válaszd, ha az igény több csomóponton át tartó folyamatos írási teljesítmény, vagy alacsony késleltetésű szűrt keresés több százmillió vektoron; az particionálás vagy kifejezetten erre épített rendszer, és a halogatás később migrációt fizettet.",{"type":465,"content":466},"quote",[467,468,469],"Nem minden beágyazó modell olyan vektorokat ad, amelyek jól kvantizálhatók. Döntés előtt a saját adatokon kell validálni."," ","— AWS Database Blog, 2026. augusztus 18.",{"type":108,"level":109,"id":97,"text":98},{"type":114,"ordered":449,"items":472},[473,478,482,486,490],[474],{"tag":475,"href":23,"children":476},"a",[477],"pgvector README: típusok, indexelés, szűrés és skálázás",[479],{"tag":475,"href":32,"children":480},[481],"pgvector changelog, 0.1.0-tól 0.8.7-ig",[483],{"tag":475,"href":35,"children":484},[485],"PostgreSQL hír: megjelent a pgvector 0.8.2 (CVE-2026-3172)",[487],{"tag":475,"href":38,"children":488},[489],"AWS: pgvector skálázása bináris kvantizálással Aurora PostgreSQL-en",[491],{"tag":475,"href":41,"children":492},[493],"pgvector licenc: a PostgreSQL licenc",[495,544,598,648],{"slug":496,"published":497,"minutes":498,"category":7,"tags":499,"keywords":504,"about":513,"sources":517,"cover":536,"og":537,"expertise":44,"locales":538,"lang":48,"title":539,"description":540,"coverAlt":541,"url":542,"pricing":543,"kind":500},"zep","2026-10-06",11,[500,501,502,503,12],"Agent memory","Knowledge graph","Temporal graph","Context engineering",[505,506,507,508,509,510,511,512],"zep ai","zep agent memory","graphiti knowledge graph","zep pricing","zep vs mem0","long-term memory for agents","temporal knowledge graph","zep cloud",[514],{"name":515,"url":516},"Zep","https:\u002F\u002Fwww.getzep.com\u002F",[518,521,524,527,530,533],{"title":519,"url":520},"Zep pricing: plans, credits and limits","https:\u002F\u002Fwww.getzep.com\u002Fpricing",{"title":522,"url":523},"Zep documentation","https:\u002F\u002Fhelp.getzep.com\u002F",{"title":525,"url":526},"Graphiti on GitHub","https:\u002F\u002Fgithub.com\u002Fgetzep\u002Fgraphiti",{"title":528,"url":529},"Graphiti product page","https:\u002F\u002Fwww.getzep.com\u002Fplatform\u002Fgraphiti\u002F",{"title":531,"url":532},"Announcing a new direction for Zep's open-source strategy","https:\u002F\u002Fwww.getzep.com\u002Fblog\u002Fannouncing-a-new-direction-for-zeps-open-source-strategy\u002F",{"title":534,"url":535},"Graphiti: temporal knowledge graphs for AI agents (arXiv)","https:\u002F\u002Farxiv.org\u002Fabs\u002F2501.13956","\u002Fimages\u002Fblog\u002Fzep\u002Fcover.webp","\u002Fimages\u002Fblog\u002Fzep\u002Fog.jpg",[46,47,48],"Zep ismertető: ügynök-memory temporális gráfon","A Zep hostolt ügynök-memory API temporális tudásgráfon: kreditek íráskor, lekérdezés ingyen, Flex 125 dollártól havonta, a Graphiti az a rész, amit magunk üzemeltethetünk.","A Zep diagramja arról, hogyan jut el egy tény a promptig: az üzeneteket és tényeket felhasználónkénti entitás- és kapcsolatgráffá bontják, a lekérdezés pedig bejárja a gráfot, és kontextusblokkot ad vissza a támasztó tényekkel.","https:\u002F\u002Fwww.getzep.com","Apache-2.0 core · Cloud from $50 per month",{"slug":545,"published":5,"minutes":546,"category":7,"tags":547,"keywords":550,"about":558,"sources":565,"cover":590,"og":591,"expertise":44,"locales":592,"lang":48,"title":593,"description":594,"coverAlt":595,"url":596,"pricing":597,"kind":560},"lancedb",9,[9,548,549,12],"Hybrid search","Embedded database",[545,551,552,553,554,555,556,557],"lancedb review","lance vector database","embedded vector database","lancedb vs qdrant","hybrid search rrf","lancedb indexing","lance data format",[559,562],{"name":560,"url":561},"Vector database","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FVector_database",{"name":563,"url":564},"Apache Arrow","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FApache_Arrow",[566,569,572,575,578,581,584,587],{"title":567,"url":568},"LanceDB quickstart","https:\u002F\u002Fdocs.lancedb.com\u002Fquickstart",{"title":570,"url":571},"LanceDB vector indexes","https:\u002F\u002Fdocs.lancedb.com\u002Findexing\u002Fvector-index",{"title":573,"url":574},"LanceDB indexing guide","https:\u002F\u002Fdocs.lancedb.com\u002Findexing\u002Findex",{"title":576,"url":577},"LanceDB hybrid search","https:\u002F\u002Fdocs.lancedb.com\u002Fsearch\u002Fhybrid-search",{"title":579,"url":580},"LanceDB Enterprise","https:\u002F\u002Fdocs.lancedb.com\u002Fenterprise",{"title":582,"url":583},"LanceDB frequently asked questions","https:\u002F\u002Fdocs.lancedb.com\u002Ffaq\u002Ffaq-oss",{"title":585,"url":586},"LanceDB pricing","https:\u002F\u002Flancedb.com\u002Fpricing",{"title":588,"url":589},"LanceDB on PyPI","https:\u002F\u002Fpypi.org\u002Fproject\u002Flancedb\u002F","\u002Fimages\u002Fblog\u002Flancedb\u002Fcover.webp","\u002Fimages\u002Fblog\u002Flancedb\u002Fog.jpg",[46,47,48],"LanceDB: vektoros keresés, amely könyvtárként indul","A LanceDB értékelése: Apache-2.0 beágyazott vektoros könyvtár szerver helyett, az IVF és HNSW indexválasztás, hibrid keresés rangsoregyesítéssel, és mit ad hozzá az Enterprise.","A LanceDB teszt borítóképe: egy Lance-tábla vektorindexet és teljes szöveges indexet táplál egy fúziós rangsorba","https:\u002F\u002Flancedb.com","Apache-2.0 · Cloud paid",{"slug":599,"published":600,"minutes":6,"category":7,"tags":601,"keywords":603,"about":609,"sources":613,"cover":641,"og":642,"expertise":44,"locales":643,"lang":48,"title":644,"description":645,"coverAlt":646,"url":612,"pricing":647,"kind":500},"mem0","2026-09-17",[500,602,12,9],"Long-term memory",[599,604,605,606,607,510,608],"mem0 review","agent memory layer","mem0 self-hosted","mem0 pricing","mem0 alternatives",[610],{"name":611,"url":612},"Mem0","https:\u002F\u002Fmem0.ai",[614,617,620,623,626,629,632,635,638],{"title":615,"url":616},"Mem0 documentation","https:\u002F\u002Fdocs.mem0.ai\u002Fintroduction",{"title":618,"url":619},"Mem0 quickstart","https:\u002F\u002Fdocs.mem0.ai\u002Fquickstart",{"title":621,"url":622},"How Mem0 works","https:\u002F\u002Fdocs.mem0.ai\u002Fcore-concepts\u002Fhow-it-works",{"title":624,"url":625},"Mem0 pricing","https:\u002F\u002Fmem0.ai\u002Fpricing",{"title":627,"url":628},"Mem0 on GitHub","https:\u002F\u002Fgithub.com\u002Fmem0ai\u002Fmem0",{"title":630,"url":631},"mem0ai on PyPI","https:\u002F\u002Fpypi.org\u002Fproject\u002Fmem0ai\u002F",{"title":633,"url":634},"Mem0 research and benchmarks","https:\u002F\u002Fmem0.ai\u002Fresearch",{"title":636,"url":637},"Mem0 MCP server","https:\u002F\u002Fdocs.mem0.ai\u002Fplatform\u002Fmem0-mcp",{"title":639,"url":640},"Mem0 paper on arXiv","https:\u002F\u002Farxiv.org\u002Fabs\u002F2504.19413","\u002Fimages\u002Fblog\u002Fmem0\u002Fcover.webp","\u002Fimages\u002Fblog\u002Fmem0\u002Fog.jpg",[46,47,48],"Mem0: mennyibe kerül egy ügynökmemória körönként","A Mem0 elemzése: körönként kinyert tények, az április 2026-i benchmark tábla platformra vonatkozó fenntartása, négy felhő-csomag és ami kimarad az önálló üzemeltetésből.","Hurok, amely a beszélgetésből tárolt tényeket készít, majd visszaolvasja őket a promptba","Free tier · from $19 per month",{"slug":649,"published":650,"minutes":6,"category":7,"tags":651,"keywords":654,"about":663,"sources":673,"cover":692,"og":693,"expertise":44,"locales":694,"lang":48,"title":695,"description":696,"coverAlt":697,"url":666,"pricing":698,"kind":560},"milvus-zilliz","2026-09-08",[9,548,652,653,12],"BM25 full text","Distributed",[655,656,657,658,659,660,661,662],"milvus","milvus vs qdrant","zilliz cloud pricing","vector database comparison","milvus hybrid search","apache milvus self-hosting","milvus 3.0","rag vector store",[664,667,670],{"name":665,"url":666},"Milvus","https:\u002F\u002Fmilvus.io",{"name":668,"url":669},"Zilliz Cloud","https:\u002F\u002Fzilliz.com",{"name":671,"url":672},"Retrieval-augmented generation","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FRetrieval-augmented_generation",[674,677,680,683,686,689],{"title":675,"url":676},"Milvus architecture overview","https:\u002F\u002Fmilvus.io\u002Fdocs\u002Farchitecture_overview.md",{"title":678,"url":679},"Milvus release notes","https:\u002F\u002Fmilvus.io\u002Fdocs\u002Frelease_notes.md",{"title":681,"url":682},"Milvus releases on GitHub","https:\u002F\u002Fgithub.com\u002Fmilvus-io\u002Fmilvus\u002Freleases",{"title":684,"url":685},"Milvus README: features and licence","https:\u002F\u002Fgithub.com\u002Fmilvus-io\u002Fmilvus",{"title":687,"url":688},"Zilliz Cloud pricing","https:\u002F\u002Fzilliz.com\u002Fpricing",{"title":690,"url":691},"Zilliz Cloud list price","https:\u002F\u002Fzilliz.com\u002Fpricing\u002Fpricing-guide","\u002Fimages\u002Fblog\u002Fmilvus-zilliz\u002Fcover.webp","\u002Fimages\u002Fblog\u002Fmilvus-zilliz\u002Fog.jpg",[46,47,48],"Milvus elemzés: a legteljesebb vektordatbázis üzemeltetve","A Milvus 3.0.2 a legteljesebb nyílt forráskódú vektordatbázis, és a legnehezebben üzemeltethető. Elemzés az architektúráról, a hibrid keresésről, a költségekről és a korlátokról.","A Milvus-ajánló címképe: folyamat az ingesttől az indexen, a keresésen és a rerankingen át","Apache-2.0 · Zilliz Cloud free tier",1791383550048]