Typy databází – SQL, NoSQL a Když si vlastně vyberu každou

„Typ databáze“ není značka. PostgreSQL a MySQL jsou obě relační. MongoDB a Firestore jsou obě úložiště dokumentů. Redis je modul klíč-hodnota, se kterým týmy zacházejí jako s mezipamětí, frontou a někdy jako s nebezpečným primárním úložištěm. Pokud si vyberete databázi, protože ji použil výukový program, vybíráte módu. Pokud si to vyberete kvůli tomu, jak jsou data tvarována a jak je aplikace dotazuje, děláte architekturu.

Toto je mapa, kterou používám, když se někdo zeptá „SQL nebo NoSQL? - obvykle špatná první otázka. První otázka zní: co je jeden řádek (nebo dokument nebo uzel) v tomto produktu, co musí zůstat konzistentní a jaké otázky bude aplikace klást tisíckrát denně?

1. Co vlastně znamená „typ“.

Tři osy jsou důležitější než marketingová kategorie. Nechte si to špatně a logo na krabici vás nezachrání.

• Datový model: tabulky se vztahy, vnořené dokumenty, klíče, grafy, časové úseky nebo vektory.
• Model dotazu: spojení, filtrování podle polí, get-by-key, procházení grafu, rozsah v čase nebo „co je blízko tomuto vložení?“
• Záruky: transakce ACID, případná konzistence, jednoduchost jednoho uzlu versus cluster, který budete ladit ve 2 hodiny ráno.

2. Relační (SQL) - výchozí pro peníze a vztahy

PostgreSQL, MySQL, SQLite. Řádky v tabulkách, cizí klíče, spojení, migrace, transakce ACID. Toto je stále ten správný domov pro většinu webových produktů: uživatele, pracovní prostory, role, objednávky, faktury, rezervace, inventář. Pokud řada musí existovat, protože existuje jiná řada, nebo se nesmí poplatek opakovat dvakrát, chcete relační motor – ne JSON blob a modlitbu.

PostgreSQL je moje výchozí nastavení v roce 2026: JSONB, když je pole skutečně bez schématu, vestavěný fulltext pro malé vyhledávání, pgvector, když se později zobrazí RAG. Než budete „potřebovat“ druhou databázi, můžete se hodně rozrůst. SQLite je podceňován pro místní aplikace, rozhraní CLI a malé produkty. MySQL je v pořádku, pokud ji tým již provozuje - nezakládám tam zelenou louku.

• Vyberte SQL, když je úkolem integrity, vytváření sestav pomocí spojení a „kdo za co v tomto pracovním prostoru zaplatil“.
• Nevybírejte SQL, protože je to „podnikové“. Vyberte si to, protože doména je graf faktů, které musí zůstat pravdivé.

3. Databáze dokumentů - flexibilní objekty, nákladné relace

MongoDB, CouchDB, Firestore, DynamoDB v režimu dokumentu. Dokument je strom JSON. To se hodí, když je pracovní jednotkou jeden objekt s vnořenými bity, které se vždy načítají společně: článek CMS, produkt s chaotickými atributy, uživatelský profil, který vždy získáte celý.

Past: stále máte uživatele, pracovní prostory a faktury. Znovu objevíte spojení v aplikaci, ztratíte transakce s více dokumenty (nebo za ně zaplatíte) a strávíte rok přidáváním pravidel jedinečnosti, která by vám relační engine dal v první den. Úložiště dokumentů používám, když má produkt tvar obsahu a vzor přístupu je „načíst tento blob podle ID“. Nepoužívám to, protože frontend mluví JSON. Postgres JSONB již mluví JSON.

4. Klíč-hodnota – Redis a přátelé

Redis, Memcached, DynamoDB jako čistý obchod klíč-hodnota. Získejte, nastavte, vyprší platnost. Volitelně seznamy, sady, pub/sub. Tady obchod s deskami nežije. Je to ta rychlá vrstva vedle ní.

• Dobré: relace, limity rychlosti, příznaky funkcí, klíče idempotence, mezipaměť drahých čtení, krátkodobé zámky.
• Špatný: jediná kopie objednávek, uživatelů nebo oprávnění. Jedno spláchnutí nebo politika vystěhování a máte noční můru s podporou.

5. Široký sloupec - když se zápis nikdy nezastaví

Cassandra, Scylla, Bigtable. Dělíte podle klíče, hodně píšete, čtete podle tohoto klíče a přijímáte, že ad-hoc SQL není smyslem. Vhodné pro telemetrii v obrovském měřítku, informační kanály ve stylu doručené pošty, velké pracovní zatížení pro zápis ve více oblastech. Špatné pro rezervaci SaaS s dvanácti stoly. Pokud ještě nemáte číslo jako „miliony zápisů za sekundu“, tuto kategorii přeskočte. Provozní náklady klastru jsou produktem.

6. Graf - když je otázkou souvislost

Neo4j, Amazon Neptune a - pro malé grafy - SQL s rekurzivními CTE. Použijte grafický modul, když je produktem síť: doporučení, podvodné kruhy, organizační schémata, dědění oprávnění, „kdo jsou dva skoky od tohoto dodavatele“. Nepoužívejte jeden, protože jste nakreslili rámečky a šipky na tabuli. Téměř každá doména má vztahy. Relační databáze již modelují vztahy. Grafové stroje si vydělají, když je dotazem hloubka průchodu, nikoli diagram schématu.

7. Časové řady - metriky, senzory, události v čase

InfluxDB, TimescaleDB, Prometheus pro ops, ClickHouse pro události ve tvaru analýzy. Pokud je každý řádek „toto zařízení nebo metrika v tomto časovém razítku“, obecné schéma OLTP bude bolet: příliš mnoho vložení, skenování rozsahu, zásady uchovávání. TimescaleDB je atraktivní, protože zůstává PostgreSQL – stejné zálohy, stejné SQL, hypertabulky pro horkou cestu. ClickHouse slouží k analýze, nikoli k pokladní transakci. Nevypisujte tabulku objednávek do stroje časové řady, protože sloupec created_at existuje.

8. Vektor - vložení, ne druhý zdroj pravdy

Pinecone, Qdrant, Weaviate a pgvector uvnitř Postgresu. Ukládáte vektory, abyste se mohli ptát „jaký text se blíží této otázce?“ Tedy RAG, sémantické vyhledávání, detekce duplicit. Článek, cena, uživatel - ti stále žijí v provozní databázi. Vektorový index je odvozený index, jako vyhledávání. Přestavte to. Nenechte na tom záviset placení nebo oprávnění.

V roce 2026 nejprve přidám pgvector do Postgresu. Vyhrazená vektorová databáze, když velikost korpusu a QPS ospravedlňují další pohyblivou část – ne proto, že by pitch deck řekl „AI-native“.

9. Vyhledávání není databáze záznamů

Elasticsearch, OpenSearch, Typesense, Meilisearch. Fulltext, tolerance překlepů, aspekty, hodnocení. Obnovte ze zdroje pravdy. Nikdy nedovolte, aby pokladna, akcie nebo oprávnění závisely pouze na indexu, který se může po neúspěšném přeindexování posunout. Pro mnoho malých katalogů stačí Postgres fulltext. Přidejte vyhledávač, když uživatelé zadávají chaotické dotazy a potřebujete relevanci, ne když vás SQL nudí.

10. Jak si vlastně vybírám

Filtry spouštím v tomto pořadí. Zásobník přichází po odpovědích, ne před srovnávací tabulkou.

• Jaká je jednotka konzistence? Pokud se peníze nebo zásoby pohybují, SQL s transakcemi. Ne „opravíme dvojky v aplikaci“.
• Co je horký dotaz? Podle ID, spojení, fulltextu, podobnosti, časového rozsahu nebo skoku v grafu? Přizpůsobte motor tomuto tvaru.
• Kdo to obsluhuje ve 2 hodiny ráno? Jeden spravovaný Postgres poráží chytrý cluster, který nikdo z týmu nedokáže odladit.
• Dokáže jeden motor pokrýt 80 %? Postgres plus Redis pokrývá většinu webových produktů, které skutečně odesílám.

Ve skutečnosti bych začal výchozím nastavením z roku 2026

Pokud datový model nenutí specialistu od prvního dne, toto je zásobník, se kterým bych otevřel – a odmítnul ho rozšířit, dokud se neobjeví změřené úzké hrdlo, nikoli příspěvek na blogu.

• PostgreSQL jako zdroj pravdy. JSONB, kde je pole skutečně bez schématu. pgvector, pokud RAG je skutečný prvek, nikoli snímek.
• Redis pro mezipaměť, relace, limity rychlosti a lehké fronty. Ne na objednávky.
• Objektové úložiště pro soubory. Vyhledávač pouze tehdy, když LIKE a Postgres FTS nestačí.

Typ je tvar díla

SQL vs NoSQL byl argument z roku 2010. Užitečná otázka v roce 2026 zní: který datový model odpovídá úloze a jak málo systémů dokážete dobře provozovat? Začněte se vztahovým zdrojem pravdy. Přidejte specializovaný obchod, když je tvar dotazu skutečně odlišný – mezipaměť, vyhledávání, vektory, časové řady. Hybridní je normální. Pět databází v první den MVP je způsob, jak experiment zemře.