Pinecone: értékelés a menedzselt vektordatabázisról

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.

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.

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.

Á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.

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.

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.

Források

1. Pinecone docs: Index data overview, indexes, namespaces and metadata
2. Pinecone docs: Adopt the Documents API, API version 2026-07
3. Pinecone docs: Create an index, schemas, regions and metrics
4. Pinecone docs: Understanding Pinecone cost, read units, write units and egress
5. Pinecone pricing: plans, limits and rates
6. Pinecone docs: Semantic search
7. Pinecone docs: Local development with Pinecone Local
8. Pinecone docs: 2026 release notes