Vektorová vs relační DB: nenahrazují se. Decision guide pro éru AI

Proč tahle otázka teď hoří

Za poslední rok mi přišlo pět klientů se závěrem: „potřebujeme vektorovou DB pro AI." Čtyři z nich ji nepotřebovali — jejich problém zvládl obyčejný Postgres. Pátý ji potřeboval, ale použil ji špatně a vyrobil chatbota který odpovídal sémanticky podobně, ale fakticky jinak.

Ta otázka tu je proto, že prodej kolem AI tlačí firmy k jednoduchému narativu: AI = embeddings = vector DB = Pinecone. Realita je méně přímočará. Vektorová a relační databáze se nenahrazují. Řeší odlišné typy otázek. Ve většině real-world stacků spolu žijí — a třetí svět, full-text search, se zapomene, ačkoli v českých firmách často nese nejvíc vyhledávání — jen o něm nikdo nemluví.

Tento článek je decision guide. Žádné benchmarky, žádný žebříček. Čtyři reálné situace které potkávám, tři pasti které opakovaně vidím u klientů, jeden default stack pro 90 % SME a tři otázky které si položte předtím, než sáhnete po čemkoli jiném než PostgreSQL.

Rámec: tři světy, ne dva

Tři typy DB, tři typy dotazů:

Relační databáze (PostgreSQL, MariaDB, MS SQL) odpovídá přesně na přesné otázky. „Dej mi všechny faktury klienta 042 z března." Index je B-tree, dotaz je SQL, výsledek je deterministický. Tohle je jádro každého business systému posledních 30 let.

Vektorová databáze (pgvector, Qdrant, Weaviate, Pinecone) odpovídá podobně na nepřesné otázky. „Najdi dokumenty sémanticky podobné formulaci 'jak reklamuji produkt'." Pod kapotou ukládá embeddings — číselné vektory které reprezentují význam textu — a hledá nejbližší přes kosinovou podobnost. Výsledek není deterministický ve smyslu SQL, je nejpravděpodobněji relevantní.

Full-text search (PostgreSQL tsvector, Elasticsearch, OpenSearch) je třetí svět který se zapomíná. Hledá na úrovni slov a frází s rankováním podle BM25. „Najdi dokumenty obsahující slova 'reklamace' nebo 'vrácení' kromě těch z roku 2022." Levný, rychlý, předvídatelný — a často je to co uživatel skutečně potřebuje.

Většina real-world řešení potřebuje dvě z těchto tří. Někdy tři. Otázka není kterou DB, ale jaký dotaz dělají moji uživatelé.

Čtyři reálné situace z praxe

1. Klasický business software (POHODA, e-shop, CRM) — relační stačí

Faktury, objednávky, stavy zásob, kontakty, mzdové údaje. Každý dotaz má přesnou formu: kdo, kdy, kolik. Žádná fuzzy logika nepomůže — když účetní hledá fakturu 2024/0042, nechce sémanticky podobnou, chce tu jednu.

Default: PostgreSQL. Pokud máte legacy MariaDB nebo MS SQL, nemigrujte jen kvůli AI hype. Indexovat a opravit pomalé queries dává 10× větší přínos než jakákoli vektorová DB. Nepotřebujete vector jen proto, že chcete dashboard nebo reporting do Slacku.

2. Chatbot nad firemními PDF / interní knowledge base — vector ano

Klient chce: „zeptej se našeho HR manuálu". Uživatel formuluje volně: „kdy mám nárok na nemocenskou?", „co s otcovskou?", „kdo mi schvaluje dovolenou?". Vector DB tu dělá těžkou práci — embeddings z relevantních pasáží se porovnávají s embeddingem otázky, top-3 chunks se pošlou do LLM jako kontext.

Default: pgvector v existujícím Postgresu. Pro 90 % use-cases je to dost. Až při 10M+ chuncích nebo SLA pod 50 ms začne mít smysl sáhnout po dedikovaném engine (Qdrant, Weaviate). O tom v sekci 5.

3. Vyhledávání v e-shopu nebo helpdesku — hybrid

Tohle je nejčastější real-world případ kterému zákazník špatně rozumí. Uživatel na e-shopu píše: „červené boty do 80 eur velikost 42". Real query má tři vrstvy:

1. Keyword („červené", „boty") → BM25 / tsvector.

2. Sémantika (synonyma, kontext, překlepy) → vector.

3. Filtr (cena ≤ 80, velikost = 42) → SQL WHERE.

Vector DB samostatně tu nestačí. Vrátit 50 sémanticky podobných bot všech barev a cen znamená frustrovaného zákazníka. Hybrid = BM25 + vector + filtr přes SQL. PostgreSQL tohle všechno umí nasadit v jednom engine — pgvector + tsvector + běžné indexy. Bez tří oddělených externích služeb.

4. AI agenti s dlouhou pamětí — vector + TTL

Agent který si pamatuje konverzace z minulých týdnů, nebo systém který se učí z field interakcí. Vector DB ano — embeddings paměti umožní find-similar při nových otázkách. Ale bez TTL strategie (time-to-live, automatické mazání po N dnech) DB nabere šum. Po třech měsících agent retrievuje irelevantní staré epizody a halucinuje.

Pravidlo palce: každý zápis dostane TTL. Jiná okna pro jiné typy vzpomínek — systémové preference 365 dní, konverzační paměť 30 dní, transakční kontext 7 dní. Tohle je častější příčina špatné UX než špatný model.

Tři pasti které opakovaně vidím

Past 1: Vendor lock-in přes Pinecone (nebo jiný proprietární SaaS)

Pinecone je dobrá služba. Jenže když vážete kritickou část stacku na proprietární endpoint bez exportu ve formátu který umí jiný engine přečíst, vážete se nejen na jejich pricing, ale i na jejich feature roadmap.

Konkrétní příklad který se stal v Q1 2026: Pinecone 2.0 zvedl read costs z $0.04 na $0.12 per 1M RU — 3× nárůst bez změny workloadu. Klienti kteří v 2024 podepsali multi-year contract se probudili s trojnásobnou fakturou a žádným mechanismem downgradu — serverless tier znamená „platíš za usage", neexistuje menší plán na který by se dalo přejít. Tohle není hypotetické riziko, tohle je letošní rok.

Spočítejte si total cost na 3 roky včetně re-embeddingu při případné migraci. Často vyjde levněji self-hosted pgvector na Hetzneru včetně DevOps režie. Konkrétní čísla níže v sekci 5.

Past 2: Vector DB jako jediný zdroj pravdy

Klient — český e-shop, ~30k objednávek ročně — postavil chatbota pro customer support. Cíl: zákazník napíše otázku, dostane odpověď s odkazem do FAQ nebo do detailu vlastní objednávky. Tým udělal to co dnes dělá každý: FAQ + reklamační řád + návody → embeddings → Pinecone → GPT-4. Pěkně to fungovalo na demo otázkách.

Spadlo to v produkci první hodinu. Zákazníci začali ptát: „kde je moje objednávka 2024/0042?". Chatbot vracel sémanticky podobné texty z FAQ — „jak sledovat balík", „životní cyklus objednávky". Protože objednávka 2024/0042 v Pinecone nebyla. Byla v Postgresu.

Lekce: vector DB je o sémantice. Když uživatel ptá fakt, potřebujete nástroj který zavolá SQL. Vector hledá podobné, ne přesné. Bez relační DB lepíte fakta ze sémantického špásu.

Řešení zabralo dvě hodiny. Přidali jsme tool calling do GPT — pokud otázka obsahuje vzor čísla objednávky nebo identifikátor, agent hodí parametrizovaný SELECT do Postgresu. Pro kontext zůstal vector. Pro fakta se použil zdroj faktů.

Past 3: Embedding model bez verzování

Vyembeddujete 5 milionů chunků modelem OpenAI text-embedding-3-small. Za šest měsíců vyjde lepší nebo levnější model. Pokud nemáte verzi modelu uloženou spolu s každým vektorem — a strategii re-embeddingu — vyhodíte celou DB. Nebo hůř: necháte v ní mix dvou modelů a vyhledávání se nedá důvěřovat.

Pravidlo: každý zápis ukládejte s embedding_model_version. Migraci dělejte jako batch job s dvojitým indexem (starý + nový), přepněte atomicky.

1ALTER TABLE chunks ADD COLUMN embedding_model_version text NOT NULL;
2
3CREATE INDEX ON chunks USING hnsw (embedding vector_cosine_ops)
4  WHERE embedding_model_version = 'text-embedding-3-small';
Copy

Partial index nad konkrétní verzí modelu — nový model nasadíte paralelně, queries zůstanou deterministické (WHERE embedding_model_version = '...' v každém dotazu), přepnete když máte re-embedding hotový.

Default stack pro 90 % českých SME

Pro malou a střední firmu která chce nasadit AI nad firemními daty mám jeden default:

PostgreSQL 16+ s pgvector + tsvector na vlastním serveru nebo přes managed (Supabase, Neon).

Decision tree podle očekávaného škálování:

1Kolik chunků očekáváte za 12 měsíců?
2
3  < 100k             → SQLite + sqlite-vec
4                       (lokální, dev, edge nasazení)
5
6  100k – 10M         → PostgreSQL + pgvector  ← default 90 % případů
7                       (Hetzner ~17 €/měs nebo Supabase Pro ~25 USD)
8
9  10M – 100M         → pgvector s tuningem (HNSW, partitioning)
10                       nebo migrace na Qdrant self-hosted
11
12  > 100M             → Qdrant / Weaviate / Milvus
13                       (tehdy už máte dedikovaný DB tým, který si vybere sám)
Copy

Konkrétní čísla — porovnání pro 1 milion chunků a mírný traffic (~5 RPS, requests per second):

• Stack: PostgreSQL + pgvector (self-hosted) · Hosting: Hetzner CCX13 (2 vCPU AMD, 8 GB RAM, 80 GB NVMe) + storage box pro zálohy · Měsíční náklad: ~17 €

• Stack: PostgreSQL + pgvector (managed) · Hosting: Supabase Pro · Měsíční náklad: ~25 USD

• Stack: Pinecone Serverless (Standard plan) · Hosting: Pinecone · Měsíční náklad: 50 USD minimum commitment, typicky 70–200 USD podle traffic-u

Pinecone Standard má od 2024 minimum commitment 50 USD/měs. Reálná faktura se při 1M chunků a středně aktivním AI agentovi pohybuje 70–200 USD/měs podle poměru reads/writes a storage (storage 0.33 USD/GB, reads 8.25 USD per 1M RU — read units, writes 2 USD per 1M WU — write units). Při produkčním workloadu s peak hours se čísla šplhají výš — Q1 2026 navýšení read costs (3×) tohle ještě zhoršilo.

Self-hosted pgvector na Hetzneru vás tedy stojí zlomek ceny Pinecone-u. Při vyšších loadech je rozdíl ještě výraznější. Navíc data zůstávají na infrastruktuře nad kterou máte plnou kontrolu — 100 % access logů, žádné třetí strany v supply chainu, žádná překvapení v ToS když vendor přijde s novým pricing modelem.

Kdy migrovat pryč od pgvector:

• Přerostli jste 10 milionů chunků a zároveň potřebujete sub-50 ms latenci na top-K queries.

• Vyhledávání tvoří 60 %+ infra nákladu a chcete dedikovaný vector engine s nižší per-vector cenou (Qdrant self-hosted nebo Weaviate Cloud).

• Potřebujete native multi-tenancy nebo geo-distribuci která v pgvector chybí.

V 9 z 10 případů tohle nikdy nepřerostete. Nezakládejte rozhodnutí v roce 2026 na hypotetickém škálování z roku 2028.

Tři otázky před rozhodnutím

Předtím, než koupíte Pinecone licenci nebo zmigrujete data, zodpovězte si tři otázky:

1. Hledají moji uživatelé přesné záznamy nebo *podobné*? Pokud přesné (faktura, kontakt, status objednávky) → relační. Pokud volné formulace nad textem → potřebujete vector + relační zároveň.

2. Stačí mi jeden DB engine, nebo potřebuji kombinaci? Ve většině případů potřebujete kombinaci (vector + SQL + někdy full-text). PostgreSQL tohle umí všechno v jednom engine. Až když narazíte na konkrétní SLA limit, dělte.

3. Jaký objem chunků budu mít za 12 měsíců, ne za 5 let? Pod 1M chunků: pgvector triviálně. 1–10M: pgvector s HNSW indexem stále v pohodě. Nad 10M: zvažte dedikovaný engine, ale spočítejte total cost včetně DevOps.

Pokud vás to zaujalo a máte konkrétní use-case který chcete posoudit — POHODA + AI, chatbot nad dokumenty, search v e-shopu — umím přijet na 1denní infra audit. Podíváme se na data, dotazy, plán. Bez závazku další spolupráce. Výstup je dokument s doporučeným stackem a 90denním migračním plánem.

Domluvit audit →