Tipuri de baze de date - SQL, NoSQL și Când le aleg de fapt pe fiecare

Un „tip de bază de date” nu este o marcă. PostgreSQL și MySQL sunt ambele relaționale. MongoDB și Firestore sunt ambele depozite de documente. Redis este un motor cheie-valoare pe care echipele îl tratează ca pe un cache, o coadă și, uneori, ca pe un magazin principal periculos. Dacă alegeți o bază de date pentru că un tutorial a folosit-o, alegeți o modă. Dacă îl alegeți din cauza modului în care sunt modelate datele și a modului în care aplicația le interogează, faceți arhitectură.

Aceasta este harta pe care o folosesc când cineva întreabă „SQL sau NoSQL?” - de obicei prima întrebare greșită. Prima întrebare este: ce este un rând (sau document, sau nod) în acest produs, ce trebuie să rămână consecvent și ce întrebări va pune aplicația de o mie de ori pe zi?

1. Ce înseamnă de fapt „tip”.

Trei axe contează mai mult decât categoria de marketing. Găsiți greșit și logo-ul de pe cutie nu vă va salva.

• Model de date: tabele cu relații, documente imbricate, chei, grafice, intervale de timp sau vectori.
• Model de interogare: îmbinări, filtrare după câmp, obținere după cheie, traversare grafică, interval în timp sau „ce este aproape de această încorporare?”
• Garanții: tranzacții ACID, eventual consistență, simplitate cu un singur nod față de un cluster pe care îl vei depana la 2 a.m.

2. Relațional (SQL) - implicit pentru bani și relații

PostgreSQL, MySQL, SQLite. Rânduri în tabele, chei străine, alăturari, migrări, tranzacții ACID. Aceasta este încă casa potrivită pentru majoritatea produselor web: utilizatori, spații de lucru, roluri, comenzi, facturi, rezervări, inventar. Dacă un rând trebuie să existe pentru că există un alt rând, sau o încărcare nu trebuie să apară de două ori, vrei un motor relațional - nu un blob JSON și o rugăciune.

PostgreSQL este implicit în 2026: JSONB când un câmp este cu adevărat fără schemă, text complet încorporat pentru căutări mici, pgvector când RAG apare mai târziu. Puteți crește mult înainte de a „avea nevoie” de o a doua bază de date. SQLite este subestimat pentru aplicațiile locale, CLI și produsele mici. MySQL este în regulă dacă echipa îl rulează deja - nu încep un teren verde acolo.

• Alegeți SQL când integritatea, raportarea cu îmbinări și „cine a plătit pentru ce în acest spațiu de lucru” sunt treaba.
• Nu alegeți SQL pentru că este „întreprindere”. Alegeți-l pentru că domeniul este un grafic de fapte care trebuie să rămână adevărate împreună.

3. Baze de date de documente - obiecte flexibile, relatii costisitoare

MongoDB, CouchDB, Firestore, DynamoDB în modul document. Un document este un arbore JSON. Aceasta este o potrivire bună atunci când unitatea de lucru este un obiect cu biți imbricați care se încarcă întotdeauna împreună: un articol CMS, un produs cu o pungă de atribute dezordonată, un profil de utilizator pe care îl obțineți întotdeauna întreg.

Capcana: mai aveți utilizatori, spații de lucru și facturi. Vei reinventa asocierile în aplicație, vei pierde tranzacții cu mai multe documente (sau vei plăti pentru ele) și vei petrece un an adăugând reguli de unicitate pe care un motor relațional ți le-ar fi dat în prima zi. Folosesc un depozit de documente când produsul are formă de conținut și modelul de acces este „încărcați acest blob după id”. Nu îl folosesc pentru că frontend-ul vorbește JSON. Postgres JSONB vorbește deja JSON.

4. Valoare-cheie - Redis și prieteni

Redis, Memcached, DynamoDB ca un magazin pur cheie-valoare. Obțineți, setați, expirați. Opțional liste, seturi, pub/sub. Nu aici trăiește afacerea cu discuri. Este stratul rapid de lângă el.

• Bine: sesiuni, limite de frecvență, steaguri de caracteristici, chei de idempotnță, cache de citiri scumpe, încuietori de scurtă durată.
• Rău: singura copie a comenzilor, utilizatorilor sau permisiunilor. O singură politică de spălare sau evacuare și aveți un coșmar de sprijin.

5. Wide-coloană - când scrierile nu se opresc niciodată

Cassandra, Scylla, Bigtable. Partițizi după o cheie, scrii mult, citești după acea cheie și accepți că SQL-ul ad-hoc nu este ideea. Potrivit pentru telemetrie la scară mare, fluxuri în stil inbox, încărcături de lucru grele de scriere în mai multe regiuni. Greșit pentru o rezervare SaaS cu douăsprezece mese. Dacă nu aveți deja un număr precum „milioane de scrieri pe secundă”, omiteți această categorie. Costul operațional al clusterului este produsul.

6. Grafic - când întrebarea este conexiunea

Neo4j, Amazon Neptune și - pentru grafice mici - SQL cu CTE recursive. Utilizați un motor de grafice atunci când produsul este în rețea: recomandări, inele de fraudă, organigrame, moștenire de permisiuni, „care este la doi hop de la acest furnizor”. Nu folosiți unul pentru că ați desenat casete și săgeți pe o tablă albă. Aproape fiecare domeniu are relații. Bazele de date relaționale modelează deja relații. Motoarele grafice își câștigă păstrarea atunci când interogarea este adâncimea de traversare, nu diagrama schemei.

7. Serii temporale - metrici, senzori, evenimente de-a lungul timpului

InfluxDB, TimescaleDB, Prometheus pentru operațiuni, ClickHouse pentru evenimente în formă de analiză. Dacă fiecare rând este „acest dispozitiv sau măsurătoare la acest marcaj de timp”, o schemă OLTP generală va dăuna: prea multe inserări, scanări ale intervalului, politici de păstrare. TimescaleDB este atractiv pentru că rămâne PostgreSQL - aceleași copii de rezervă, același SQL, hypertables pentru calea caldă. ClickHouse este pentru analiză, nu pentru tranzacția de plată. Nu aruncați tabelul de comenzi într-un motor de serie temporală, deoarece coloana create_at există.

8. Vector - înglobări, nu o a doua sursă de adevăr

Pinecone, Qdrant, Weaviate și pgvector în Postgres. Stocați vectori astfel încât să puteți întreba „ce text este aproape de această întrebare?” Adică RAG, căutare semantică, detectarea dublelor. Articolul, prețul, utilizatorul - cei mai trăiesc în baza de date operațională. Indexul vectorial este un index derivat, precum căutarea. Reconstruiește-l. Nu lăsați plata sau permisiunile să depindă de acestea.

În 2026, adaug mai întâi pgvector la Postgres. O bază de date vectorială dedicată atunci când dimensiunea corpusului și QPS justifică o altă parte în mișcare - nu pentru că un pitch deck spune „AI-native”.

9. Căutarea nu este o bază de date de înregistrare

Elasticsearch, OpenSearch, Typesense, Meilisearch. Text integral, toleranță la greșeli de scriere, fațete, clasare. Reconstruiește din sursa adevărului. Nu lăsați niciodată ca achiziția, stocul sau permisiunile să depindă doar de un index care poate varia după o reindexare eșuată. Textul integral Postgres este suficient pentru multe cataloage mici. Adăugați un motor de căutare atunci când utilizatorii introduc interogări dezordonate și aveți nevoie de relevanță, nu atunci când v-ați plictisit de SQL.

10. Cum aleg de fapt

Rulez filtrele în această ordine. Stiva vine după răspunsuri, nu înainte de tabelul de comparație.

• Care este unitatea de consistență? Dacă banii sau inventarul se mișcă, SQL cu tranzacții. Nu „vom repara dublurile în aplicație”.
• Care este interogarea fierbinte? După id, alăturare, text integral, similaritate, interval de timp sau hop grafic? Potriviți motorul cu acea formă.
• Cine operează asta la 2 a.m.? Un Postgres gestionat învinge un cluster inteligent pe care nimeni din echipă nu îl poate depana.
• Un motor poate acoperi 80%? Postgres plus Redis acoperă majoritatea produselor web pe care le expediez de fapt.

Un implicit 2026 cu care aș începe de fapt

Cu excepția cazului în care modelul de date obligă un specialist din prima zi, acesta este stiva cu care aș deschide - și aș refuza să mă extind până când apare un blocaj măsurat, nu o postare pe blog.

• PostgreSQL ca sursă a adevărului. JSONB unde un câmp este cu adevărat fără schemă. pgvector dacă RAG este o caracteristică reală, nu un diapozitiv.
• Redis pentru cache, sesiuni, limite de rată și cozi ușoare. Nu pentru comenzi.
• Stocarea obiectelor pentru fișiere. Un motor de căutare numai atunci când LIKE și Postgres FTS nu sunt suficiente.

Tipul este forma lucrării

SQL vs NoSQL a fost un argument din anii 2010. Întrebarea utilă în 2026 este: ce model de date se potrivește cu jobul și cât de puține sisteme poți rula bine? Începeți cu o sursă relațională de adevăr. Adăugați un magazin specializat atunci când forma interogării este cu adevărat diferită - cache, căutare, vectori, serii temporale. Hibridul este normal. Cinci baze de date în prima zi a unui MVP este modul în care experimentul moare.