> Mitennyibe kerül valójában a Pinecone: a read unit a namespace méretével skálázódik, a sémát utólag nem lehet módosítani, és hol érdemes saját vektordatabázist futtatni. > > Web page: https://balazscsorba.com/hu/blog/pinecone · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/pinecone.md) · [Deutsch](https://balazscsorba.com/de/blog/pinecone.md) > Author: Balázs Csorba · Published: 2026-07-09 · Keywords: pinecone vector database, pinecone pricing, pinecone read units, pinecone namespaces, pinecone vs qdrant, pinecone vs pgvector, pinecone documents api, serverless vector database cost [Blog](https://balazscsorba.com/hu/blog)/Retrieval és keresés # Pinecone: értékelés a menedzselt vektordatabázisról Mitennyibe kerül valójában a Pinecone: a read unit a namespace méretével skálázódik, a sémát utólag nem lehet módosítani, és hol érdemes saját vektordatabázist futtatni. [Balázs Csorba](https://balazscsorba.com/hu/about)·2026\. július 9.·11 perc olvasás - Vector search - Embeddings - RAG - Namespaces - Hybrid search ![Nagy keret három növekvő részre osztva, bal üres, jobb tele, sarokban zár.](https://balazscsorba.com/images/blog/pinecone/cover.webp?v=2dd14579ba) ## A lényeg röviden - A Pinecone a leolvasásokra számláz, nem a vektorokra. Egy query egy read unitba kerül a beolvasott namespace minden gigabájtra, 0,25 read unit a minimum, így a particionálás az a döntés, amely meghatározza a számlát. - A Standard csomagban a read unit négyszerese a write unitnak, 16 és 18 US dollár millióként szemben 4 és 4,50 dollárral. Egy olvasás-intenzív retrieval alkalmazást egyetlen tétel dominál. - Egymillió query egy 50 GB-os namespace-en Standarden körülbelül 800 US dollár havonta. Ugyanez az egymillió query 100 darab 0,5 GB-os namespace-en körülbelül 8 dollár. Az alkalmazáson semmi nem változik. - A dokumentum indexeken a séma migráció nem támogatott, és a 2026-07 API verzió előtt létrehozott index soha nem kerül át a Documents API-ra. Egy új mező új indexet és újra betöltést jelent. - Az Enterprise alatt nincs rendelkezésreállási SLA, az Enterprise pedig 500 US dollár havi minimumtól indul. A Starter csomag egyetlen régióra korlátozott. Ezen az oldalon 1. [Mi ez](https://balazscsorba.com/#what-it-is) 2. [Hogyan működik](https://balazscsorba.com/#how-it-works) 3. [Hol törik el](https://balazscsorba.com/#where-it-breaks) 4. [Első lépések](https://balazscsorba.com/#getting-started) 5. [Árazás](https://balazscsorba.com/#pricing) 6. [Alternatívák](https://balazscsorba.com/#alternatives) 7. [Ítélet](https://balazscsorba.com/#verdict) 8. [Források](https://balazscsorba.com/#sources) Cikk meghallgatása 0:000:00 A PINECONE az a menedzselt vektordatabázis, amelyen a legtöbb retrieval prototípus indul, és jó okkal: egy index egy POST-ra van, nincs mit futtatni, és a számlát méritek, nem lemérnek. Ez a kombináció egy retrieval funkció első évében valóban nehezebben verhető. Ugyanez az oka annak is, hogy Pinecone gyakran már nem a megfelelő alapértelmezés, ha egy terméknek valódi forgalma van, mert az árazási modell egy olyan döntést jutalmaz, amelyet a csapatok ritkán hoznak meg tudatosan — hogy hogyan particionált az adat. Kétféle dologgal verseng. Az egyik oldalon azok az általános adatbázisok, amelyek vektoroszlopot kaptak: pgvector a PostgreSQL-ben, MongoDB Atlas, Redis. A másik oldalon a célzott motorok, Qdrant és Weaviate, saját üzemeltetéssel vagy a felhőben. Az ellenük szóló érv üzemeltetési: nincs klaszter, nincs újraindexelés, nincs ANN hangolás, a kapacitás akkor jelenik meg, amikor kell. A visszaérték a vendor lock-in, a querynélküli... a skálánál jelentkező költség, és egy adatmodell, amely szándékosan nem SQL. ## Mi ez Az index minden alapegysége. A rekordok egy indexbe kerülnek, a queryk egy indexre céloznak, és a belsejükben az adatok namespace-ekre vannak osztva, ahol minden upsert, query, fetch és list pontosan egy namespace-t céloz. A 2026-07 API verzió óta kétféle index létezik, és különbségük megértése a legfontosabb, mielőtt kódot ír valaki a Pinecone ellen. - A vector index a klasszikus: sűrű és opcionálisan ritka vektorok, `dimension`, `metric` és `vector_type` paraméterekkel jön létre, a Vectors API-n olvassuk és írjuk. - A document index az új: egy séma, amely `dense_vector`, `sparse_vector` és teljes szövegű `string` mezőket deklarál, a Documents API-n olvassuk és írjuk. - A namespace-ek az első upsertnél jönnek létre. Tenantonként egy a dokumentált multitenant minta, és a namespace szerinti particionálás a lekérdezési költséget is csökkenti. - A metaadatok lapos JSON objektumok: nincs beágyazott objektum, nincs null érték, a kulcsok nem kezdődhetnek `$`\-szel, az egészek 64 bites lebegőpontként tárolódnak, és 40 KB a rekordonkénti plafon. Minden indexelésre kerül, hacsak nem másképp konfiguráljuk. - A szűrőnyelv egy dokumentált részhalmaz: `$eq`, `$ne`, `$gt`, `$gte`, `$lt`, `$lte`, `$in`, `$nin`, `$exists` plusz `$and`, `$or` és `$not`. A listaoperátorok legfeljebb 10.000 értéket fogadnak. - A ritka indexek szűkek: legfeljebb 2.048 nem nulla érték vektoronként, 10 upsert másodpercenként, 100 query másodpercenként, `top_k` maximum 10.000, és kizárólag dot product metrika. ## Hogyan működik Egy indexben három rangsorolási jel élhet együtt: BM25 a teljes szövegű mezőkön, sűrű vektorok a jelentésre, ritka vektorok a tanult lexikális súlyra. Vector indexen a hibrid query egy hívásban kombinálja a sűrűt és a ritkát. Document indexen egy keresés egyetlen pontozási típus szerint rangsorol, a `score_by` választja ki, tehát a hibrid keresés ott vagy egy szöveges szűrő, amely a sűrű keresés előtt szűkíti a jelölteket, vagy két keresés, amelyeket az alkalmazásban reciprocal rank fusionnel fúzionálunk. ![Pinecone: dokumentumok és vektorok namespace-ekbe, queryk ki A teljes szövegű mezőket tartalmazó dokumentumok, sűrű vektorok és ritka vektorok egy serverless indexbe kerülnek, amely namespace-ekre van osztva. Egy query egy namespace-t nevez meg, a beolvasott namespace minden gigabájtra egy read unitba kerül, 0,25 read unit a minimum, metaadat szűrővel szűkíthető, és pontozott találatokat ad vissza, amelyek válaszbytejai egressként számlázódnak.](https://balazscsorba.com/images/blog/pinecone/diagram-7.webp?v=1a05416a3e) Az árazási modell ugyanebből a szerkezetből következik: a query az index megcélzott részéért fizet, nem a végzett munkáért. Az árazási modell ugyanebből a szerkezetből következik. Egy query egy read unitba kerül a beolvasott namespace minden gigabájtra, 0,25 read unit a minimum. A `top_k`, `include_metadata` és `include_values` nem változtat rajta semmit; csak a namespace mérete számít. Az egrest külön mérik a visszaadott bitekre, az ID-k és a pontok is beleszámítanak. Az index körül ott van három további szolgáltatás, amelyeket érdemes megnevezni, mert megváltoztatják, mit kell megtennie az alkalmazásnak: a Pinecone Inference embedding- és reranking modelleket hostol, és tokenekre vagy rerank kérésekre számol; a Pinecone Assistant a feltöltött dokumentumkészletből chat végpontot csinál saját token- és ingestion méréssel; a Pinecone Nexus pedig, agent knowledge engine-ként felsorolva, ugyanezt az ötletet viszi tovább azzal, hogy a retrieval egyszer történik meg az adat változásakor, nem minden agent híváskor. ## Hol törik el Négy dolog fog bele, és ezek közül három strukturális, nem javítható. - A séma migráció nem támogatott. Egy létrehozott dokumentum indexhez nem lehet mezőt hozzáadni, eltávolítani vagy módosítani, és a dokumentált megoldás az index törlése és egy új létrehozása. - Átkonvertálni nem lehet. Az index data plane-je létrehozáskor rögzül, így az SDK frissítése sosem viszi át a régi vector indexet a Documents API-ra. Aki teljes szöveges keresést akar, második indexet épít és újra betölt. - A cloud és a régió létrehozás után nem változtatható, a Starter csomag pedig `aws` `us-east-1` régióra korlátozott. Ami adatrezidencia követelményt tartalmaz, az már az első napon fizetős csomagos döntés. - Az olvasási költség a namespace méretével skálázódik, nem a munkával. Egy 50 GB-os namespace 50 read unitba kerül querynként; ugyanaz az adat 100 darab 0,5 GB-os namespace-ben 0,5-be. Ez százszoros a legnagyobb tételben. - Az Enterprise alatt nincs rendelkezésreállási SLA, az Enterprise pedig 500 dolláros havi minimumtól indul. A Standard, amelyre a legtöbb produkciós terhelés kerül, sem SLA-t, sem audit logot nem kap. - A Pinecone Local, a lokális emulátor, a 2025-01 API verziót futtatja, egy indexet 100.000 rekordra korlátoz, figyelmen kívül hagyja az API kulcsokat, és nem támogat namespace-eket, mentést vagy Pinecone Inference-t. Ez CI kényelem, nem hű lokális környezet. Vegyük a dokumentált díjakat és számoljunk. Standarden a read unit cloudtól és régiótól függően 16 és 18 dollár millióonként. Egymillió query egy 50 GB-os namespace-en 50 millió read unit, tehát havonta körülbelül 800 dollár csak olvasásra. Ugyanez az egymillió query 100 darab 0,5 GB-os namespace-ben 500.000 read unit, azaz nagyjából 8 dollár. Az alkalmazáson semmi nem változott, csak a particionáláson. Az Enterprise-on, ahol a read unit 24 dolláron milliónként indul, ugyane két szám 1.200 és 12 dollár lesz. **A namespace költségszabályozó, nem séma-részlet** A namespace-eket multitenant használatra és lekérdezési sebességre dokumentálták. Az árazási modell költségszabályozóvá is teszi őket, és ez a legnehezebben felfedezhető a Pinecone-ban. A tenantonkénti namespace egyszerre izolációs mechanizmus és az a mechanizmus, amely megakadályozza, hogy egy nagy ügyfél szabja meg mindenki olvasási árát. A következmény kellemetlen. A prícingoldal átviteli példái azért tűnnek bőkezűnek, mert egy kis index beleül a 0,25 read unit minimumba; ugyanez a forgalmi minta egy 10 GB-os namespace-ben querynként a negyvenszeresébe kerül. ## Első lépések A legkisebb hasznos Pinecone program egy vector index a saját embeddingjeinkkel, tenantonként egy namespace, és egy metaadat szűrő a queryben. Ide convergeál a legtöbb produkciós kód, és ez az a forma, amelyet az árazási modell jutalmaz. ``` import os from pinecone import Pinecone, ServerlessSpec pc = Pinecone(api_key=os.environ["PINECONE_API_KEY"]) if not pc.has_index("products"): pc.create_index( name="products", vector_type="dense", dimension=1536, metric="cosine", spec=ServerlessSpec(cloud="aws", region="eu-central-1"), deletion_protection="disabled", ) index = pc.Index("products") # One namespace per tenant keeps each read inside a small slice of the index. index.upsert( namespace="tenant-42", vectors=[("p-1001", embedding, {"category": "pumps", "price": 249.0})], ) hits = index.query( namespace="tenant-42", vector=query_embedding, top_k=8, filter={"category": {"$eq": "pumps"}, "price": {"$lte": 500}}, include_metadata=True, include_values=False, # omit the vector: egress is billed on the response ) ``` A snippet két részlete teherviselő. A `include_values=False` az alapértelmezés, és több kilobájtot tart ki találatonként az egress számlából, míg egy `fetch` mindig visszaadja a vektorértékeket, szóval `query`\-t használj, ha keresel és csak azonosítókat vagy metaadatokat kérsz. És a `filter` nem csökkenti a read unitokat: ezt a namespace teszi. A szűrők a már kiválasztott namespace-en belül szűkítik a beolvasott halmazt, ami még egy ok arra, hogy ne mindent tegyünk egyetlen namespace-be. **Először az index fajtáját válasszuk** Ha a tervben BM25 is szerepel, a sémás document index az egyetlen út, és a sémát utána nem lehet módosítani. Ha sűrű és ritka vektorokról van szó kombinált queryvel, maradjunk vector indexen, ahol a hibrid keresés egyetlen hívás. Mindkét fajta minden csomagban elérhető. A döntésnek nem a licencelhez, hanem a tartóssághoz van köze. ## Árazás Négy csomag, mindegyik más alakú. A Starter ingyenes, merev keretekkel, a Builder havi 20 dollár fix, a Standard és az Enterprise pedig használat alapú havi minimum mögött, amely inkább vállalásként viselkedik, nem díjként. Starter Standard Enterprise Havi minimum $0 $50 $500 Tárhely Legfeljebb 2 GB Korlátlan, $0,33 GB-nként havonta Korlátlan, $0,33 GB-nként havonta Write unit Legfeljebb 2M havonta Korlátlan, $4 és $4,50 millióonként Korlátlan, $6 és $6,75 millióonként Read unit Legfeljebb 1M havonta Korlátlan, $16 és $18 millióonként Korlátlan, $24 és $27 millióonként Egress 1 GB havonta 100 GB benne, utána $0,10 GB-nként 100 GB benne, utána $0,10 GB-nként Irányítás Community support, egy projekt SSO, RBAC, mentés és visszaállítás Audit logok, privát végpontok, CMK, SCIM, 99,95% SLA Három megjegyzés. Az 50 és az 500 dolláros minimumot kiegészítő tételként számlázzák, ha a használat alatta marad, szóval egy csendes hónap is a minimumba kerül. A Standardben a read unit négyszerese a write unitnak, ami azt jelenti, hogy egy olvasás-intenzív retrieval alkalmazást egyetlen tétel ural. A és a lapos díjas csomagok nem esnek szépen: a keret túllépése után a beolvasó kérések 429 hibával blokkoltak, nem kiszámlázva, ami egészen más hibaminta, mint a meglepő számla, és vitathatóan a kettő közül a jobb. A Standard és az Enterprise azt is feloldja, amit egy produkciós beállítás végül igényel: import object storage-ból 0,25 dollár GB-nként, mentés 0,10 dollár GB-nként havonta, visszaállítás 0,15 dollár GB-nként, valamint dedicated read node-ok, amelyek egyáltalán nem read unitban mérődnek, hanem a kiépített kapacitás alapján áraznak. A dedicated read node-ok azok a funkciók, amelyeket meg kell érteni, mielőtt bárki úgy dönt, hogy a Pinecone túl drága, mert megtörik a read unit formulát, amelyen a cikk többi része áll. ## Alternatívák Az érdemi összehasonlítás nem minden vektordatabázis. Hanem az a kettő, amely egy konkrét, strukturált módon töri meg a Pinecone modellt. Pinecone Qdrant pgvector Licenc és üzemeltetés Saját tulajdon; menedzselt serverless AWS-en, Azure-on vagy GCP-n Apache-2.0; saját üzemeltetés vagy Qdrant Cloud PostgreSQL licenc; egy oszlop a saját adatbázisodban Hibrid keresés Egy index tartalmaz dense, sparse és BM25 adatot, de a document index kérésenként egy jellel rangsorol Egy query a dense, sparse és BM25 pontokat összekeveri Te kombinálod a ts\_vector-t és a vektorindexet Egy query költsége 1 read unit namespace GB-nként, minimum 0,25 A géped, amelyen fut, vagy cloud node-ok A már fizetett Postgres számla része Az alak megváltoztatása A séma nem változik; index új és újratöltés A payload mezők rebuild nélkül bővíthetők ALTER TABLE, majd az ANN index megépítése SQL és joinok Nincs; nincs join, nincs tranzakció Nincs; szűrés a payloadon át Teljes SQL a vektorok és a sorok felett együtt A táblázat őszinte összegzése: a pgvector mindent nyer, kivéve a méretet, és a küszöb valahol tízmillió vektornál van, ami felett a PostgreSQL-ben az indexépítési idők és a recall hangolása már nem egy kényelmes délután. A Qdrant nyer a kontrollnál és az egyetlen queryben végzett hibrid keresésnél, és veszít azon, hogy valakinek futtatnia kell. A Pinecone nyer az első query idejénél és abban, hogy egy keresőszolgáltatáshoz nem kell ügyeletet szervezni, és veszít a queryenkénti költségen, amikor az index megnő, és abban, hogy az adat alakját utólag nem lehet megváltoztatni. Ezek az egyezések, egyik sem hiba. ## Ítélet A Pinecone a helyes alapértelmezés egy retrieval funkció első kilencven napjára, és elfogadható választás évekig, ha a terhelés kicsi, jól particionált, és elég nehéz ahhoz, hogy a read unit minimumon üljön. Akkor szűnik meg a helyes válasz, ha az index meghalad néhány gigabájtot, ha egy megfelelési követelmény SLA-t vagy audit logokat kér, vagy ha a korpusz alakja még mozgásban van. 1. Vedd át, ha senki sem fog kereső klasztert tulajdonolni. Az ingyenes csomag valóban hasznos, az első fizetős lépés 20 dollár fix. 2. Particionálj namespace-ekre, mielőtt nagy az index, nem utána. Ez az egyetlen döntés állítja be az olvasási számlát, és később sokkal nehezebb megváltoztatni. 3. Ne vedd át document indexet olyan korpuszra, amelynek mezői még mozgásban vannak, mert a séma migráció nem támogatott. 4. Számolj a saját namespace méreddel. A read unit képlet a dokumentációban elég rövid ahhoz, hogy zsebszámológéppel kijöjjön. 5. Nézd meg a Qdrantot, ha az index meghalad tízmillió vektort, és a pgvectort, ha jelentősen egy millió alatt marad, és van már adatbázisadminisztrátorod. **Ha ma döntesz** A \[pgvector összehasonlítás\](/blog/pgvector-vs-vector-databases) mélyebben kezeli az open source oldalt, a \[hibrid keresés és reranking\](/blog/rag-pipeline-chunking-hybrid-search-reranking) pedig azt, mi mozgatja valójában a recallt. A retrieval minőségét a chunkelés, az embedding választás és a reranking dönti el jóval korábban, mint az indeximplementáció. Menedzselt adatbázist retrieval minőségi alapon választani azt jelenti, hogy a legkevésbé fontos változón választasz. ## Források 1. [Pinecone docs: Index data overview, indexes, namespaces and metadata](https://docs.pinecone.io/guides/index-data/indexing-overview) 2. [Pinecone docs: Adopt the Documents API, API version 2026-07](https://docs.pinecone.io/guides/index-data/adopt-the-documents-api) 3. [Pinecone docs: Create an index, schemas, regions and metrics](https://docs.pinecone.io/guides/index-data/create-an-index) 4. [Pinecone docs: Understanding Pinecone cost, read units, write units and egress](https://docs.pinecone.io/guides/organizations/manage-cost/understanding-cost) 5. [Pinecone pricing: plans, limits and rates](https://www.pinecone.io/pricing/) 6. [Pinecone docs: Semantic search](https://docs.pinecone.io/guides/search/semantic-search) 7. [Pinecone docs: Local development with Pinecone Local](https://docs.pinecone.io/guides/operations/local-development) 8. [Pinecone docs: 2026 release notes](https://docs.pinecone.io/release-notes/2026) ## Gyakori kérdések Mi a Pinecone, és mire használják? A Pinecone teljesen menedzselt vektordatabázis. Embeddingeket tárol egy indexben, és hasonlóság alapján kérdezi le őket, ez a retrieval lépés egy RAG pipeline-ban, a szemantikus termékkeresésben és az agent memoryben. Menedzselt serverless infrastruktúrán fut AWS-en, Azure-on vagy GCP-n, tehát nincs karbantartandó klaszter. Mennyibe kerül havonta a Pinecone? A Starter csomag ingyenes, és havonta 2 GB tárhelyet, 2 millió write unitot, 1 millió read unitot és 1 GB egresset tartalmaz. A Builder havi 20 dollár fix. A Standard havi 50 dollár minimum, a tárhely 0,33 dollár GB-nként havonta, a write unit 4 és 4,50 dollár millióként, a read unit 16 és 18 dollár millióként, az egress a benne foglalt 100 GB után 0,10 dollár GB-nként. Az Enterprise havi 500 dollártól indul, 24 és 27 dollár millió read unittal. Mi a különbség a Pinecone vector index és a document index között? A vector index a klasszikus, dimension, metric és vector\_type paraméterekkel jön létre, sűrű és ritka vektorokat tart a Vectors API-n keresztül, és egy queryben ad hibrid keresést. A document index sémával jön létre a Documents API-n keresztül, és egy indexben tud sűrű vektort, ritka vektort és teljes szövegű mezőket is tartani, de egy keresés egyetlen pontozási típus szerint rangsorol, tehát a hibrid keresés ott vagy egy szöveges szűrő a dense keresés előtt, vagy két keresés, amelyeket az alkalmazásban fúzionálni kell. A Pinecone namespace-ek csak multitenant használatra valók? Dokumentálva multitenant használatra és lekérdezési sebességre vannak, de az árazási modell költségszabályozóvá is teszi őket, és ez a legnehezebben felfedezhető a Pinecone-ban. Egy query egy read unitba kerül a beolvasott namespace minden gigabájtra, így a tenantonkénti namespace megakadályozza, hogy egy nagy ügyfél szabja meg az olvasási árat mindenkinek. Módosíthatom később a Pinecone index sémáját? Nem. A Pinecone dokumentációja egyértelműen kimondja, hogy a séma migráció még nem támogatott: létrehozott dokumentum indexhez nem lehet mezőt hozzáadni, eltávolítani vagy módosítani, és a dokumentált megoldás az index törlése és egy új létrehozása. Ugyanez vonatkozik a cloudra és a régióra is, amelyek szerver nélküli index létrehozása után nem változtathatók meg. Van ingyenes csomag, és lehet-e lokálisan fejleszteni? A Starter csomag ingyenes, merev keretekkel és egy projekttel. Lokális fejlesztéshez létezik a Pinecone Local, egy memóriában futó Docker emulátor, de a jelenlegi helyett a 2025-01 API verziót futtatja, egy indexet 100.000 rekordra korlátoz, figyelmen kívül hagyja az API kulcsokat, és nem támogat namespace-kezelést, mentést vagy Pinecone Inference-t, így inkább CI kényelem, mint hű lokális környezet. Í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 - [Embedding-modell választása 2026-ban: ranglisták, költségek és összehasonlító teszt a saját adatokon](https://balazscsorba.com/hu/blog/embedding-model-selection-2026) - [Kontextuális visszakeresés és késleltetett chunkolás: a RAG-chunkok visszakapják a kontextusukat](https://balazscsorba.com/hu/blog/contextual-retrieval-late-chunking) - [Hozzáférés-kezelés RAG-hoz: jogosultságtudatos visszakeresés dokumentumszivárgás nélkül](https://balazscsorba.com/hu/blog/rag-access-control-permissions) - [RAG termékkatalógusra: PIM-adatokból megbízható válaszok](https://balazscsorba.com/hu/blog/rag-product-catalog-pim-data) ## Pont erre van szükséged? Írj a projektedről vagy a pozícióról – szívesen hallok felőled. [Lépj velem kapcsolatba](mailto:contact@balazscsorba.com) [Kapcsolódjunk LinkedInen](https://www.linkedin.com/in/balazs-csorba)