Типи баз даних - SQL, NoSQL і коли я насправді обираю кожну

«Тип бази даних» - це не бренд. PostgreSQL і MySQL обидві реляційні. MongoDB і Firestore - обидві документні. Redis - рушій ключ-значення, який команди тримають як кеш, чергу і іноді як небезпечне головне сховище. Якщо обираєте базу, бо так було в уроці - обираєте моду. Якщо обираєте через форму даних і те, як застосунок їх запитує - робите архітектуру.

Це карта, якою я користуюсь, коли питають «SQL чи NoSQL?» - зазвичай це хибне перше питання. Перше питання: що є одним рядком (документом, вузлом) у цьому продукті, що має лишатися узгодженим, і які питання застосунок ставитиме тисячу разів на день?

1. Що насправді означає «тип»

Три осі важливіші за маркетингову категорію. Помиліться в них - логотип на коробці не врятує.

• Модель даних: таблиці зі зв’язками, вкладені документи, ключі, графи, часові кошики або вектори.
• Модель запитів: джойни, фільтр по полю, get-by-key, обхід графа, діапазон у часі або «що близько до цього ембедінгу?»
• Гарантії: ACID-транзакції, eventual consistency, простота одного вузла проти кластера, який розгрібатимете о другій ночі.

2. Реляційні (SQL) - стандарт для грошей і зв’язків

PostgreSQL, MySQL, SQLite. Рядки в таблицях, зовнішні ключі, джойни, міграції, ACID-транзакції. Це досі правильний дім для більшості вебпродуктів: користувачі, робочі простори, ролі, замовлення, рахунки, бронювання, склад. Якщо рядок має існувати, бо існує інший, або списання не має статись двічі - потрібен реляційний рушій, а не JSON і молитва.

PostgreSQL - мій стандарт у 2026: JSONB, коли поле справді без схеми, вбудований full-text для малого пошуку, pgvector, коли пізніше з’явиться RAG. Можна довго рости, перш ніж «потрібна» друга база. SQLite недооцінений для local-first, CLI і крихітних продуктів. MySQL нормальний, якщо команда вже на ньому живе - з нуля я туди не стартую.

• Обирайте SQL, коли задача - цілісність, звіти з джойнами і «хто за що заплатив у цьому робочому просторі».
• Не обирайте SQL бо це «ентерпрайз». Обирайте, бо домен - граф фактів, які мають бути правдивими разом.

3. Документні бази - гнучкі об’єкти, дорогі зв’язки

MongoDB, CouchDB, Firestore, DynamoDB у документному режимі. Документ - це дерево JSON. Це пасує, коли одиниця роботи - один об’єкт із вкладеними шматками, які завжди тягнуться разом: стаття CMS, товар із мішком атрибутів, профіль користувача, який завжди читаєте цілком.

Пастка: у вас усе одно є користувачі, робочі простори й рахунки. Ви винайдете джойни в застосунку, втратите мультидокументні транзакції (або заплатите за них) і рік додаватимете унікальність, яку реляційний рушій дав би в перший день. Документне сховище ставлю, коли продукт схожий на контент, а патерн доступу - «завантажити цей блоб за id». Не ставлю, бо фронтенд говорить JSON. Postgres JSONB уже говорить JSON.

4. Ключ-значення - Redis і компанія

Redis, Memcached, DynamoDB як чисте сховище ключ-значення. Get, set, expire. За бажанням списки, сети, pub/sub. Тут не живе система обліку. Це швидкий шар поруч із нею.

• Добре: сесії, rate limit, перемикачі функцій, ключі ідемпотентності, кеш дорогих читань, короткі блокування.
• Погано: єдина копія замовлень, користувачів чи прав. Один flush або eviction - і нічний кошмар підтримки.

5. Wide-column - коли записи не зупиняються

Cassandra, Scylla, Bigtable. Партиціонуєте за ключем, багато пишете, читаєте за цим ключем і приймаєте, що ad-hoc SQL - не про це. Пасує для телеметрії на величезному масштабі, стрічок як inbox, write-heavy у кількох регіонах. Не пасує для booking-SaaS із дванадцятьма таблицями. Якщо у вас ще немає цифри на кшталт «мільйони записів на секунду» - цю категорію пропускайте. Операційна ціна кластера і є продукт.

6. Графові - коли питання саме у зв’язку

Neo4j, Amazon Neptune і - для малих графів - SQL із рекурсивними CTE. Графовий рушій варто брати, коли продукт - це мережа: рекомендації, шахрайські кільця, оргструктури, наслідування прав, «хто за два кроки від цього постачальника». Не беріть його, бо намалювали квадрати й стрілки на дошці. Майже кожен домен має зв’язки. Реляційні бази вже моделюють зв’язки. Графові рушії окупаються, коли глибина обходу - це запит, а не схема на діаграмі.

7. Time-series - метрики, сенсори, події в часі

InfluxDB, TimescaleDB, Prometheus для ops, ClickHouse для аналітичних подій. Якщо кожен рядок - «цей пристрій або метрика в цей timestamp», звичайна OLTP-схема болітиме: забагато вставок, range-скани, політики зберігання. TimescaleDB привабливий тим, що лишається PostgreSQL - ті самі бекапи, той самий SQL, hypertables для гарячого шляху. ClickHouse - для аналітики, не для транзакції на касі. Не звалюйте таблицю замовлень у time-series, бо є колонка created_at.

8. Векторні - ембедінги, не друге основне сховище

Pinecone, Qdrant, Weaviate і pgvector у Postgres. Вектори зберігають, щоб питати «який текст близький до цього питання?» Це RAG, семантичний пошук, дедуплікація. Стаття, ціна, користувач - живуть в операційній базі. Векторний індекс - похідний, як пошук. Його перебудовують. Не робіть так, щоб каса чи права залежали від нього.

У 2026 я спочатку додаю pgvector до Postgres. Окрему векторну базу - коли розмір корпусу й QPS виправдовують ще одну рухому частину. Не тому, що в інвесторській презентації написали «AI-native».

9. Пошук - не база обліку

Elasticsearch, OpenSearch, Typesense, Meilisearch. Full-text, толерантність до помилок, фасети, ранжування. Перебудовуйте з основного сховища. Ніколи не робіть касу, склад чи права залежними лише від індексу, який може розійтися після невдалого реіндексу. Postgres full-text вистачає багатьом малим каталогам. Пошуковий рушій додавайте, коли користувачі пишуть брудні запити і потрібна релевантність - не коли набрид SQL.

10. Як я насправді обираю

Фільтри проганяю в такому порядку. Стек з’являється після відповідей, не до таблиці порівнянь.

• Що є одиницею узгодженості? Якщо рухаються гроші чи склад - SQL із транзакціями. Не «дублі поправимо в застосунку».
• Який гарячий запит? За id, джойн, full-text, схожість, діапазон часу чи крок графа? Рушій під цю форму.
• Хто це оперуватиме о другій ночі? Один managed Postgres кращий за хитрий кластер, який ніхто в команді не розгрібає.
• Чи покриє один рушій 80%? Postgres плюс Redis покривають більшість вебпродуктів, які я реально віддаю в прод.

Стандарт 2026, з якого я б реально почала

Якщо модель даних з першого дня не змушує брати спеціаліста, я б відкрила цей стек - і не розширювала б його, доки не з’явиться виміряне вузьке місце, а не стаття в блозі.

• PostgreSQL як основне сховище. JSONB там, де поле справді без схеми. pgvector, якщо RAG - реальна фіча, а не слайд.
• Redis для кешу, сесій, rate limit і легких черг. Не для замовлень.
• Об’єктне сховище для файлів. Пошуковий рушій - лише коли LIKE і Postgres FTS уже не вистачає.

Тип - це форма задачі

SQL проти NoSQL була суперечка 2010-х. Корисне питання у 2026: яка модель даних пасує до задачі і як мало систем ви можете добре оперувати? Почніть із реляційного основного сховища. Додавайте спеціалізоване сховище, коли форма запиту справді інша - кеш, пошук, вектори, time-series. Гібрид - норма. П’ять баз у перший день MVP - так експеримент помирає.