> A Chroma Apache-2.0 licencű vektadatbázis, amely beágyazottan, egyetlen csomóponton vagy Chroma Cloudként fut. Hol kényelmes, és hol ér véget a jó keresési funkciók a felhő határán.
>
> Web page: https://balazscsorba.com/hu/blog/chroma · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/chroma.md) · [Deutsch](https://balazscsorba.com/de/blog/chroma.md)
> Author: Balázs Csorba · Published: 2026-07-20 · Keywords: chroma vector database, chroma vs qdrant, chroma vs pgvector, hybrid search reciprocal rank fusion, self-hosted vector database, chroma cloud pricing, metadata filtering vector search

[Blog](https://balazscsorba.com/hu/blog)/Retrieval és keresés

# Chroma: egyszerű vektorkeresés egy bökkenővel

A Chroma Apache-2.0 licencű vektadatbázis, amely beágyazottan, egyetlen csomóponton vagy Chroma Cloudként fut. Hol kényelmes, és hol ér véget a jó keresési funkciók a felhő határán.

[Balázs Csorba](https://balazscsorba.com/hu/about)·2026\. július 20.·10 perc olvasás

-   Vector search
-   Embeddings
-   RAG
-   Hybrid search
-   Metadata filter

![Három egymásba ágyazott doboz balra, egy fal egy kapuval és két kis négyzet a falnál.](https://balazscsorba.com/images/blog/chroma/cover.webp?v=ff8c2789d3)

## A lényeg röviden

-   A Chroma Apache-2.0 licencű, körülbelül 27 000 GitHub-csillaga van, és ugyanaz az API fut Python-, TypeScript- és Rust-klienssel.
-   A beágyazott kliens az alkalmazás folyamatában indul, így az első kollekcióhoz nem kell szerver és nem kell konténer.
-   A reciprok rank fúziós hibrid keresés csak a Chroma Cloudban létezik; a dokumentáció az egycsomópontos támogatást jövőbeli munkaként nevezi.
-   A felhős árak használatalapúak: 2,50 $ GiB-onkénti írásra, 0,33 $ GiB-onkénti tárolásra havonta, 0,0075 $ TiB-onkénti lekérdezésre és 0,09 $ GiB-onkénti visszaküldésre.
-   Atisztességes mérleg: kiváló alapértelmezés az első visszakeresési réteghez, gyenge hosszú távú otthon egy komoly hibrid keresési rendszerhez.

Ezen az oldalon

1.  [Mi ez](https://balazscsorba.com/#what-it-is)
2.  [Hogyan működik](https://balazscsorba.com/#how-it-works)
3.  [Első lépések](https://balazscsorba.com/#getting-started)
4.  [Hibrid keresés és a felhő vonala](https://balazscsorba.com/#hybrid-search)
5.  [Árak és az egy lekérdezésre jutó költség](https://balazscsorba.com/#pricing)
6.  [Saját üzemeltetés: mi fut valójában](https://balazscsorba.com/#self-hosting)
7.  [Hol gyengül](https://balazscsorba.com/#where-it-shingles)
8.  [Ítélethoz](https://balazscsorba.com/#verdict)
9.  [Források](https://balazscsorba.com/#sources)

Cikk meghallgatása

0:000:00

A Chroma nyílt forráskódú vektadatbázis, Apache-2.0 licencsel, amely beágyazott könyvtárként egy alkalmazásban, egyetlen chroma run folyamatként vagy Chroma Cloudként fut. A teszt álláspontja egyszerű: ez a legjobb alapértelmezés egy RAG-rendszer első visszakeresési rétegéhez, mert egy üres repository és egy működő lekérdezés közötti súrlódás majdnem nulla — viszont rossz hosszú távú otthon egy komoly hibrid keresési rendszerhez, mert a lekérdezési nyelv érdekes részei a dokumentáció szerint csak a felhőben léteznek.

A stackben egyetlen helyet foglal el: az embeddingek tárolása és visszakeresése. Versenytárs a pgvector, ha az alkalmazás már fut Postgresen, a Qdrant vagy a Milvus, ha a visszakeresésnek saját szolgáltatás kell, és a Pinecone, ha senki nem akar üzemeltetni semmit. A Chroma egyedi tétele nem az index, hanem a kezelhetőség: a kollekcióhoz kötött embedding funkció, egy szűrőnyelv, amelyhez nem kell indexdeklaráció, és Python-, TypeScript- és Rust-kliensek, amelyek ugyanazt az API-t beszélik.

## Mi ez

Az adatmodell három szintből áll. Egy tenant tartalmaz adatbázisokat, egy adatbázis kollekciókat, és a kollekció a tárolás és lekérdezés egysége: minden bejegyzésnek van azonosítója, embeddingje és opcionálisan dokumentuma és metaadat-objektuma. A hozzáférésszabályozás, a kvóta és a számlázás tenant-szinten van definiálva, ami többbérlős SaaS esetén számít, és a legtöbb egypontos vektortárban csendben hiányzik.

-   Licenc: Apache 2.0, körülbelül 27 000 csillag a GitHub-repóban, és egy 1.5.9 verziójú kiadás 2026 májusából.
-   Három üzemmód: beágyazott könyvtár, egyetlen csomópont, és az a elosztott telepítés, amelyet a Chroma Cloud üzemeltet.
-   Három kliens — Python, TypeScript és Rust — azonos collection, add, query és get alakzattal, plusz egy aszinkron HTTP kliens.
-   Négy keresési mód egy kollekcióban: sűrű vektorok, ritka vektorok, teljes szöveg és regex a dokumentumokon, valamint metaadat-szűrés.
-   Embedding funkciók mint interfész, így a kollekció íráskor beágyaz, és a query\_texts-hez nem kell modellhívás az alkalmazáskódban.
-   Két lekérdezési API: a klasszikus query és get, valamint egy újabb Search API rangolási kifejezésekkel, elérhető a Chroma Cloudban.

## Hogyan működik

A Chroma a tartósságot olyan alrendszerekre bízza, amelyeket nem kell újra feltalálnia: helyben SQLite, az elosztott buildben felhős objektumtároló, ahol a forró adatok SSD gyorsítótárban ülnek. A gyártó érve itt nem egzotikus, hanem gazdasági — a vektorok nagyok, a memória drága, így az igazság forrásának objektumtárolóban tartása a RAM költségének töredékével teszi lehetővé a felhős árat.

![A Chroma visszakeresési útja Négy lépés. Betöltés: a darabok azonosítókkal, dokumentumokkal és metaadatokkal érkeznek, egy embedding funkció létrehozza a vektorokat. Index: egy kollekcióban egymás mellett vektorindex, ritka index, teljes szöveges index és metaadatindex található. Lekérdezés: egy vektor, egy where szűrő a metaadaton és egy where_document szűrő a tárolt szövegen szűkítik a jelöltek halmazát a rangsorolás előtt. Rangsorolás: a klasszikus query API távolságokat ad vissza, a felhős Search API viszont sűrű és ritka rangsorokat von össze reciprok rank fúzióval. Alattuk egy sáv: egy csomópont mindenent egy processzben tart SQLite fölött, a Chroma Cloud elosztott motort futtat objektumtárolón SSD gyorsítótárral.](https://balazscsorba.com/images/blog/chroma/diagram-7.webp?v=5a557d6d2b)

Mindkét módban azonos az API, amíg a Search API szóba nem jön, és pontosan ott szűnik meg a két termék felcserélhetősége.

Amit a gyártó nem tesz közzé, az egy nyilvános benchmark, aminek lenne módszertana. A felhős dokumentáció azt állítja, hogy a termelési rendszerek meghaladják a 90 százalékos recall értéket, és hogy a tárolási kialakítás egy nagyságrenddel olcsóbbá teszi a Chroma Cloudot az alternatíváknál; mindkettő hihető, és egyik sem reprodukálható a dokumentációból. Kezdd a saját értékelésed pontjának, ne eredménynek.

## Első lépések

A beágyazott kliens szervert indít a folyamatban, és a program leállásakor mindent elveszít, ami teszthez pontosan jó, termeléshez pontosan rossz. Egy minimális lekérdezéshez kliens, kollekció, upsert és query kell — szerver, konténer és indexhangolás nélkül.

```
import chromadb

client = chromadb.Client()
collection = client.get_or_create_collection("docs")

collection.upsert(
    ids=["d1", "d2"],
    documents=[
        "Refunds are issued within five business days.",
        "Support answers within one working day.",
    ],
    metadatas=[{"topic": "billing"}, {"topic": "support"}],
)

hits = collection.query(
    query_texts=["how fast is a refund?"],
    where={"topic": "billing"},
    n_results=1,
)

# Results are column-major: one list per query, one entry per result.
print(hits["documents"][0][0])
```

Ebben a részletben három dolog okozza később a legtöbb súrlódást. Az eredmények oszlopos formában érkeznek, így minden fogyasztónak párhuzamos tömböket kell összevégeznie a rekordok helyett. Az n\_results alapértelmezetten 10, ami egy kis tesztkollekción csendben nem ad használható eredményt. A szűrő pedig a where argumentumba megy a metaadaton, míg a szöveges illesztés a tárolt dokumentumon a where\_documentban fut, $contains vagy regex formájában.

**Szűrőoperátorok**

A metaadat-szűrő támogatja az összehasonlító operátorokat, `$gt` és `$lte`, a tagságosságot `$in` és `$nin` operátorokkal, a logikai összekapcsolást `$and` és `$or` segítségével, valamint 2026 februárja óta a `$contains` és `$not_contains` operátort tömb metaadatmezőkön. Indexdeklaráció nem kell, ami kényelmes, amíg egy szűrő lassú nem lesz, és akkor nincs mit állítani.

## Hibrid keresés és a felhő vonala

A Search API az query és get helyébe összeállítható kifejezést tesz: a Search építi a szűrőt és a limitet, a Knn adja a rangsorolást, az Rrf pedig több rangsort von össze. A reciprok rank fúzió minden jelöltet úgy értékel, mint a súly és a simítási állandó plusz a rangsor összegének negatív hányadosát, ahol k alapértelmezetten 60 — ezért működik a sűrű és a ritka eredmények között anélkül, hogy két különböző skálát normálni kellene.

```
from chromadb import Search, K, Knn, Rrf

dense = Knn(
    query="how fast is a refund?",
    key="#embedding",
    return_rank=True,
    limit=200,
)
sparse = Knn(
    query="how fast is a refund?",
    key="sparse_embedding",
    return_rank=True,
    limit=200,
)

search = (
    Search()
    .where(K("topic") == "billing")
    .rank(Rrf(ranks=[dense, sparse], weights=[0.7, 0.3], k=60))
    .limit(10)
    .select(K.DOCUMENT, K.SCORE)
)

rows = collection.search(search).rows()[0]
for row in rows:
    print(row["score"], row["document"][:60])
```

**Három csapda a Search API-ban**

A dokumentáció szerint kizárólag Chroma Cloudban érhető el, az egycsomópontos támogatás egy későbbi kiadásra van ütemezve, tehát ez a kód nem fut magán üzemeltetett szerveren. **return\_rank=True** kötelező minden Knn-en belül egy Rrf-ben — kihagyva a komponensek távolságokat adnak rangsorok helyett, és hihető, de csendben hibás rangsorolást kapsz. A score-ok növekvő sorrendben vannak, tehát a kisebb a jobb, szemben a klasszikus API távolságaival.

## Árak és az egy lekérdezésre jutó költség

A Chroma Cloud négy külön számlálót vezet, és az érdekes nem a vektortár. Az írás 2,50 $ GiB-onként, a tárolás 0,33 $ GiB-onként havonta, a lekérdezések 0,0075 $ TiB-onként, a kimenő forgalom pedig 0,09 $ GiB-onként a visszaküldött adatra számol. A Starter csomag nulla havi díjat kér és 5 $ kreditet, tíz adatbázist és tíz csapattagot tartalmaz; a Team havi 250 $ mellett 100 $ kreditet, száz adatbázist, harminc tagot és SOC II-t ad.

Felhős csomagDíjSzámlálókTartalom

Starter0 $ havontaírás, tárolás, lekérdezés, hálózat5 $ kredit, 10 adatbázis, 10 tag

Team250 $ havontaugyanaz a négy számláló100 $ kredit, 100 adatbázis, 30 tag, SOC II

EnterpriseEgyéniugyanaz a négy számlálókorlátlan adatbázis, single tenant, BYOC, SLA

Írás

GiB-onként

2,50 $

egyszer számolódik betöltéskor

Tárolás

GiB-onként havonta

0,33 $

vektorok plusz dokumentumok plusz metaadat

Lekérdezés

TiB-onként

0,0075 $

a legtöbb korpuszméretnél gyakorlatilag ingyenes

Hálózat

visszaküldött GiB-onként

0,09 $

a számláló, amely a nagy eredményeket bünteti

Saját szerver

0 $

saját lemez

Apache-2.0, egy csomópont, nincs Search API

A gyártó saját kalkulátora tanulságos. 1536 dimenzióval, 8 KiB-os dokumentumokkal és 500 kollekcióval egymillió dokumentum kb. 34 $ba kerül beírásra, hatmillió tárolt dokumentum havonta kb. 27 $, tízmillió lekérdezés kb. 19 $ — nagyjából 79 $ havonta egy hatmilliós darabos korpuszra. Figyeld az ekonomia irányát: 1 GiB szövegből körülbelül 15 GiB vektor lesz, tehát a tárolást a leggyorsabban növekvő számra számlázzák, és a rövid darabok helyett teljes dokumentumok visszaküldése az, ami felhajtja a kimenő forgalmi számlálót.

## Saját üzemeltetés: mi fut valójában

A saját üzemeltetés nem egyetlen dolgot jelent. Az architektúra-dokumentáció három módot különböztet meg eltérő felső korlátokkal, és a köztük lévő különbség nagyobb, mint a márkanevek sugallják.

-   Beágyazott: a chromadb.Client() a folyamatban fut, memóriában vagy helyi útvonalon tartja az adatot, és meghal a programmal. Teszthez jó, szolgáltatáshoz nem.
-   Egy csomópont: chroma run --path egy HttpClient mögött, dokumentálva kevesebb mint 10 millió rekordra, néhány kollekcióra. Tartós, egyszerű, egyetlen hibaforrás.
-   Elosztott: az a telepítés, amelyet a Chroma Cloud üzemeltet, objektumtárolós perzisztenciával és SSD gyorsítótárakkal, adatbázisonként egy régióhoz kötve.
-   Adatelhelyzet: a Chroma Cloud az AWS us-east-1 mellett 2026 áprilisától a GCP europe-west1 régióban is fut. A régió létrehozáskor fix, a költözés új adatbázist és újraindexelést jelent.
-   Megfelelés: a Chroma Cloud SOC 2 Type II tanúsított; az ügyfél által kezelt titkosító kulcsok 2025 decemberében, a privát hálózat 2026 januárjában érkezett.

**A régióválasztás végleges**

Az EU-régió minden csomagon elérhető, és teljes API-paritást ad a kollekciókhoz, a kereséshez és a forkinghoz — de a Chroma Sync, a Chroma CLI és a Search Agent induláskor csak az Egyesült Államokban érhető el. Ha egy terv ezekre épül, a létrehozáskor hozott régiódöntés nem vonható vissza.

## Hol gyengül

A gyengeségek jönnek elsőként, mert ők döntik el a választást. A hibrid rangsorolás csak a felhőben van. A metaadat-szűrés kényelmes, nem hangolható, és egy lassú szűrőhöz nincs index, amit állítanál. Az eredményforma oszlopos, ami minden fogyasztótól kis, de állandó adót szed. Az árlista pedig pontos azt a mintát bünteti, amit a retrieval-augmented generation ösztönöz: nagy kontextusablakot adni vissza lekérdezésenként.

TelepítésHibrid keresésLock-in profil

Chromabeágyazott, egy csomópont, felhőRRF csak Chroma CloudbanApache-2.0 szerver; a Search API nem az

pgvectorkiterjesztés a meglévő Postgresbenkézi: vektorindex plusz SQL teljes szövegPostgres licenc; nincs mit elhagyni

Qdrantsaját szerver vagy felhőnatívan sűrű plusz ritkaApache-2.0; szűrőterheltes dizájn elsajátítandó

Pineconecsak menedzseltnatívan a menedzselt API-bannincs saját üzemeltetési út

Licenc

Apache 2.0

PostgreSQL licenc

Apache 2.0

proprietáris

Üzemeltetési költség

a legalacsonyabb

nincs, ugyanaz az példány

egy szolgáltatás, amit futtatni kell

nincs

Dimenziókorlátok

nincs dokumentálva

2.000 a vectoron, 4.000 a halfvecen

nincs dokumentálva

nincs dokumentálva

Legjobb felhasználás

első visszakeresési réteg

vektorok a sor mellett

szűrőterheltes visszakeresés

semmilyen üzemeltetés

Az összehasonlítás, ami számít, a pgvectoré. Ha a korpusz már egy Postgres táblában van, és a vektoroknak ugyanabban a tranzakcióban kell lenniük, egy külön vektortár egy további szolgáltatás, amit menteni, biztonságoskodni és felügyelni kell olyan képességért, amit a Postgres már tud adni — a standard vector típus 2 000 dimenziós kemény korlátjával és 4 000-rel fél pontosságnál. A Chroma akkor érdemli meg a helyét, ha a visszakeresés a termék: multimodális kollekciók, regex a tárolt dokumentumokon, kollekció-forking kísérletekhez, és egy embedding funkció, amely kivesz egy modellhívást az alkalmazáskódból.

## Ítélethoz

A Chroma egy jól mérlegelt alapértelmezés egy meghatározott vakfolttal. A kezelhetőség valódi: három kliens, egy API, egy séma nélküli szűrőnyelv, és tíz sor az import chromadbtól a rangsorolt eredményig. A vakfolt ugyanilyen valós: az a lekérdezési funkcionalitás, ami a demót megkülönbözteti a visszakeresési rendszertől, pontosan az, amit ma nem tudsz magad üzemeltetni. Az első réteghez észszerű csere, egy hosszú életű rendszerhez rossz.

1.  Válaszd, ha a visszakeresési réteg még tervezés alatt áll, és a mérhető alaphoz vezető leggyorsabb út a legfontosabb.
2.  Válaszd, ha az embeddingeknek, a dokumentumoknak és a metaadatnak egy kollekcióban kell élniük, és a csapat eleve többbérlős.
3.  Válaszd olyan prototípushoz, amit később lecserélnek; a collection API elég kicsi ahhoz, hogy az újraírás egy nap, nem egy negyedév.
4.  Kerüld el, ha a hibrid keresésnek ma a saját hálózatodon belül kell maradnia — a Search API ott nem elérhető.
5.  Kerüld el, ha a korpusz már Postgresben van, és a pgvector dimenziókorlátja nem szúr.
6.  Gondolj újra róla, amikor a korpusz átlép néhány millió darabot és a single node korlátai érvénybe lépnek, vagy amikor a visszaküldött GiB-onkénti forgalom uralja a számlát.

**Az egyetlen, amit jól kell csinálni**

Kössz explicit embedding funkciót a kollekcióhoz, és rögzítsd a modellverziót a saját konfigurációdban. Az alapértelmezett embedding funkció kényelmes, és megváltozik alattad, a korpusz újra-beágyazása pedig az egyetlen migráció ebben a stackben, ami valóban drága.

## Források

1.  [Chroma dokumentáció: bevezetés](https://docs.trychroma.com/docs/overview/introduction)
2.  [Chroma: architektúraáttekintés](https://docs.trychroma.com/reference/architecture/overview)
3.  [Chroma: első lépések az SDK-val](https://docs.trychroma.com/docs/overview/getting-started)
4.  [Chroma: query és get](https://docs.trychroma.com/docs/querying-collections/query-and-get)
5.  [Chroma: metaadat-szűrés](https://docs.trychroma.com/docs/querying-collections/metadata-filtering)
6.  [Chroma Cloud: Search API áttekintés](https://docs.trychroma.com/cloud/search-api/overview)
7.  [Chroma Cloud: hibrid keresés RRF-fel](https://docs.trychroma.com/cloud/search-api/hybrid-search)
8.  [Chroma Cloud: árak](https://www.trychroma.com/pricing)
9.  [Chroma changelog](https://www.trychroma.com/changelog)

## Gyakori kérdések

Ingyen lehet-e a Chromát magán üzemeltetni?

Igen. A szerver Apache-2.0 licencű, fut helyi könyvtárként, egyetlen chroma run folyamatként vagy konténerként. A Chroma Cloud a fizetős, menedzselt réteg fölötte, és a kettő ugyanazt az API-t beszéli.

Támogatja a Chroma a hibrid keresést?

Csak a Chroma Cloudban. A Search API reciprok rank fúziót kínál sűrű és ritka embeddingeken, és a dokumentáció egyértelműen kimondja, hogy az egycsomópontos támogatás egy későbbi kiadásra van ütemezve.

Mekkora korpuszt bír egy Chroma példány?

Az architektúra-dokumentáció az egycsomópontos Chromát kevesebb mint 10 millió rekordra, néhány kollekcióra becsüli. A nagyobb munkaterhekre a Chroma Cloud mögötti elosztott telepítés szánt.

Chroma vagy pgvector?

A pgvector nyer, ha a vektorok már egy Postgres sorban élnek, és a tranzakciós konzisztencia számít. A Chroma nyer, ha a visszakeresés a termék: gazdagabb keresési módok, multimodális kollekciók és egy kliens, amely beágyazza helyetted.

Í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)