Vector DB vs. SQL DB: kdy který přístup funguje lépe?

Definice a klíčové rozdíly

Vector DB je databáze optimalizovaná pro ukládání a dotazování nad vektorovými reprezentacemi (embeddings). Umožňuje rychlé vyhledávání podobnosti (nearest neighbors) v desítkách až stovkách milionů vektorů, podporuje approximate indexy (ANN), filtrování podle metadat a často i hybridní skórování a reranking. Typické volby: spravovaná služba (např. Pinecone) nebo samo-hostované varianty (např. Weaviate, Milvus).

SQL DB (zejména PostgreSQL) je univerzální relační databáze s ACID garancemi, integritou a bohatým optimalizátorem dotazů. Dnes ji lze rozšířit o vektorové sloupce a podobnostní dotazy (např. pomocí pgvector) a kombinovat je s full-textem, agregacemi, pohledy a rolemi. Na malých a středních korpusech tak SQL pokryje překvapivě mnoho sémantických scénářů bez přidávání další technologie.

• Yes/And, ne Either/Or: vektorové a SQL přístupy se spíše doplňují: SQL drží strukturu, audit a řízení přístupů; Vector DB dodává škálovatelnou sémantiku a rychlé ANN.
• Rozhoduje kontext: objem dat, SLA (p95/p99), multimodalita, filtrování, rozpočet a provozní kapacity týmu.

Přehledové tabulky (rychlá orientace)

1) Rozhodovací matice podle situace

2) Funkční srovnání platforem

3) Nákladová struktura (TCO)

Jak fungují vektory, podobnost a ANN

• Embeddings: převod obsahu do bodu ve vysoké dimenzi; podobné objekty → blízko u sebe.
• Metriky podobnosti: kosinová podobnost, L2, skalární součin. Volba ovlivní škálování i kvalitu.
• Approximate Nearest Neighbor (ANN): rychlejší než přesné hledání; drobná ztráta recallu za dramaticky nižší latenci.
• Indexy: grafové (např. HNSW) vs. kvantizační (např. IVF, PQ). Každý má parametry ovlivňující paměť a p95/p99.
• Metadata filtering: rychlé předfiltrování kandidátů (jazyk, práva, čas) před samotnou podobností.
• Reranking: přesnější, ale pomalejší model na malé kandidátní množině pro finální pořadí.

Porovnání hlavních indexačních přístupů

Kdy (a jak) stačí SQL/pgvector

1. Korpus v řádu tisíců až nízkých milionů a benevolentní p95/p99 (řádově stovky ms až nízké sekundy).
2. Silná závislost na transakcích/ACL (audit, integrita, složité JOINy, reporting).
3. Rychlé MVP (co nejméně nových technologií, jednoduchá operativa, osvědčené zálohy/HA).
4. Smíšené dotazy (část čistě strukturovaná a část sémantická; v SQL snadno zkombinujete).

• Praktický vzor: tabulka dokumentů + tabulka chunků + vektorový sloupec + FTS indexy + pomocná tabulka metadat.
• Pozor na dimenzi vektorů a počet kandidátů; bez „chytrých“ indexů může p99 růst, jak dataset roste.

Kdy dává smysl dedikovaná Vector DB

• Velká měřítka (10M+ vektorů), potřeba stabilní p95/p99 a rychlé filtrování metadaty.
• Multimodalita (obraz, zvuk, kód, text) a cross-lingual dotazy.
• Elasticita (nárazové špičky, synchr. ingest, backfill, noční reindexace bez výpadků).
• Hybridní vyhledávání „na jeden dotaz“ a vestavěný reranking.

Hybridní strategie: lexical + vector + metadata + reranking

Proč: lexical (BM25 a spol.) je nepřekonatelný pro přesné názvy/kódy a krátké dotazy; vektor drží význam u volného jazyka. Jejich vážené spojení typicky zvyšuje celkovou spokojenost uživatelů.

Vzorové „pipeline patterny“

1. Filter → Vector → Rerank: SQL zúží korpus (jazyk, práva, platnost), Vector DB dá top-k, reranker finálně seřadí.
2. Vector → ACL → Business Rules: rychlý ANN, poté validační krok přístupů a obchodních pravidel (např. region, dostupnost).
3. Score Fusion: vážený součet lexical + vector skóre, případně Reciprocal Rank Fusion.

Váhování skóre (orientační guideline)

Referenční architektura pro RAG a vyhledávání

1. Ingest & normalizace: čištění, deduplikace, segmentace (chunking), enrich metadat.
2. Embeddings: volba modelu, verze, dimenze; evidence verzí pro audit a reindexaci.
3. Úložiště: Vector DB pro embeddings + SQL pro zdroj/dokumenty/ACL/audit.
4. Dotazovací pipeline: filtry → ANN → reranking → (RAG) → validace výstupu.
5. Observabilita: metriky latence po fázích, recall@k, kvalita citací, cost per good answer.
6. Governance: ACL, RBAC/ABAC, data residency, retence, právo být zapomenut.

Metriky kvality a výkonu (co opravdu měřit)

• Kvalita: recall@k, precision@k, nDCG@k, MRR; u RAG navíc groundedness a přesnost citací.
• Výkon: p50/p95/p99 latence (celkem i rozpad: filtrování, ANN, reranking), propustnost (RPS/QPS), TTFB.
• Náklady: cena/1k dotazů, cena/GB embeddings, egress, cena za reindexaci; cost-per-good-answer.
• Stabilita: chybovost (technická vs. sémantická), drift dat (změna mixu dotazů), kvalita napříč segmenty.

Příklad cílových SLO

• p95 latence vyhledávání ≤ 750 ms; p99 ≤ 1500 ms při N = 10M vektorů.
• nDCG@10 ≥ 0,75 na zlaté sadě; recall@50 ≥ 0,95.
• Validita přístupových pravidel (ACL pass-rate) ≥ 99,9 %.
• Cost-per-good-answer stabilní v intervalu ±10 % po releasu.

Tuning Vector DB (indexy, parametry, ingest)

1. Data & metadata: kvalitní chunking (např. 400–1200 tokenů dle domény), jednotná normalizace, povinná metadata pro filtraci.
2. Index parametry: testujte varianty pro rovnováhu p95 vs. recall; nedůvěřujte cizím defaultům, měřte na svém korpusu.
3. Kandidáti & rerank: netahejte do rerankeru zbytečně stovky dokumentů; správný „cutoff“ zásadně šetří čas i peníze.
4. Údržba indexů: konsolidace segmentů, kompakce, plánované rebuildy při změně embeddings (duální běh dvou verzí).
5. Topologie: shardování podle tenantu/jazyka, lokální peering, snížení egress.

Tuning SQL (indexy, FTS, partitioning, pgvector)

• FTS indexy: GIN/GiST pro text, pravidelný ANALYZE; hlídejte, že plánovač bere správný index.
• Partitioning: časový/tenantí; zkracuje p95/p99 a zjednodušuje údržbu.
• Vektorový sloupec: držte rozumnou dimenzi a limit kandidátů; sledujte p99 při růstu N.
• Materializované pohledy: pro populární dotazy/filtry; zrychlují hybridní patterny.
• Monitoring plánů: odhalte chybějící indexy a zbytečné full-scany dřív, než to ucítí uživatel.

Náklady a TCO: rozpočet, egress, reindexace

Počítejte dopředu: cena/GB embeddings + cena dotazů + egress + reindexace při změně modelu + lidská evaluace + čas týmu. Finální metrika: cena za dobrou odpověď (takovou, která splní vaše kvalitativní prahy).

Jednoduchý rámec rozpočtu

Bezpečnost, governance a compliance

• ACL a role: udržujte přístupová pravidla na úrovni dokumentu/chunku; validace po retrievu.
• PII/PHI: klasifikace, maskování, minimální nutná data; právo být zapomenut i na úrovni embeddings.
• Šifrování: v klidu i přenosu; auditní logy dotazů nad citlivým obsahem.
• Data residency: umístění indexů; multi-tenant izolace (namespace/shard).
• Lineage: verze embeddings, indexu, chunkingu; reprodukovatelnost při incidentech.

Observabilita a SLO/SLI

• SLI: p95/p99, nDCG@k, recall@k, ACL pass-rate, cost-per-good-answer, chybovost (technická vs. sémantická).
• Alerty: krátká okna pro p99 a 5xx/timeouty; delší okna pro kvalitu a náklady.
• Runbooky: co snížit (hloubku prohledávání, top-k, vypnout rerank), jak ověřit návrat do normálu.
• Zlaté sady: stabilní koš dotazů pro srovnání verzí embeddings/indexů/rerankerů.

Migrace a rollout (PoC → canary → produkce)

1. PoC: reprezentativní vzorek, baseline metriky (kvalita, p95/p99, náklady).
2. Šedý provoz: paralelní dotazy do nové vrstvy, pouze logování a srovnání výsledků.
3. Canary rollout: 1–5 % provozu; tvrdé podmínky pro automatický rollback.
4. Plné nasazení: post-mortem, cleanup starých indexů, plán reindexací a verzování.

Kontrolní seznamy (rychlá praxe)

Checklist: když volíte SQL + vektory

• Máme p95/p99 cíle v sekundách, ne v desítkách ms.
• Korpus ≤ nízké miliony, bez extrémně špičkových QPS.
• Silná potřeba transakcí, JOINů, reportingu a ACL.
• FTS + vektorový sloupec + partitioning + monitoring plánů.
• Plán růstu: kam až to unese, kdy přidat Vector DB.

Checklist: když volíte Vector DB

• N definováno (počet vektorů dnes/za 12 měsíců), cílové p95/p99.
• Parametry indexů a strategie filtrů metadat.
• Reranking a jeho nákladový „cutoff“.
• Strategie reindexace při změně embeddings (duální běh).
• Observabilita, SLO/SLI a runbooky.

Checklist: hybrid

• Váhování lexical vs. vector, testováno na zlaté sadě.
• ACL validace po retrievu (žádné „úniky“ mezi tenants).
• Segmentace podle jazyka/regionu/role pro přesnější filtry.
• Citace v RAG a kontrola jejich přesnosti.

Modelové scénáře z praxe

1) Znalostní báze (interní, 50k–200k článků)

• Architektura: PostgreSQL + pgvector + FTS; jednoduchý reranking.
• Výsledek: nízké náklady, rychlé MVP, p95 ~ stovky ms až 1–2 s.
• Pozor: udržujte zlatou sadu dotazů a plán růstu pro případný přechod na Vector DB.

2) E-commerce vyhledávání (10M+ položek, více jazyků)

• Architektura: Hybrid – lexical pro názvy/kódy, vektor pro sémantiku, SQL pro ceny/stock/ACL.
• Výsledek: vyšší celková relevance, stabilní p95/p99, lepší konverze vyhledávání.
• Pozor: adaptivní cutoff pro reranking a pečlivá práce s metadaty.

3) Právní/finanční screening (citlivý obsah)

• Architektura: SQL pro governance, audit, verze; Vector DB pro sémantiku precedentů.
• Výsledek: auditovatelnost + kvalita podobnostního vyhledávání.
• Pozor: ACL validace po retrievu, retence na úrovni chunku, auditní logy.

FAQ: stručné odpovědi

Můžeme zůstat jen u SQL?

Ano, pokud korpus a SLA nejsou extrémní. Mějte plán přechodu, až narazíte na limity p95/p99 či velikosti N.

Proč hybrid?

Lexical vyhrává na přesné dotazy, vektor na neurčité. Spolu dávají stabilně nejlepší relevanci.

Jak měřit kvalitu?

Recall@k, nDCG@k, MRR na zlaté sadě dotazů; u RAG navíc přesnost citací a groundedness.

Co s náklady na reindexaci?

Plánujte noční okna a duální běh dvou indexů; předem si spočítejte čas i cenu.

Jak chránit PII?

Klasifikace, maskování, RBAC/ABAC, audit, právo být zapomenut i na úrovni embeddings.

Závěr a doporučení

Vector DB a SQL DB nejsou soupeři, ale nástroje pro různé vrstvy téhož problému. SQL exceluje v transakcích, integritě, ACL a analytice; Vector DB dodává škálovatelnou sémantiku, nízkou p95/p99 a multimodalitu. V menším a středním rozsahu je SQL s vektory skvělou volbou pro MVP a interní vyhledávání. Jakmile rostou požadavky na latenci, recall, multimodalitu a filtrování, vyplatí se dedikovaná vektorová vrstva. V enterprise praxi nejčastěji vítězí hybrid: lexical + vector + metadata + reranking, s jasnými SLO a observabilitou. Rozhodujte podle metrik (nDCG@k, recall@k, p95/p99, cost-per-good-answer), mějte plán reindexací a governance a iterujte na vlastním korpusu – jen tak získáte řešení, které je rychlé, relevantní, auditovatelné i ekonomicky udržitelné.