← Назад в блог

SQLite vs PostgreSQL vs MySQL vs NoSQL: полное сравнение баз данных в 2026 году

SQLitePostgreSQLNoSQLAI-разработкаАрхитектура

Выбор базы данных — одно из ключевых архитектурных решений для любого проекта. Каждая система создавалась для решения конкретных задач, и «лучшей» базы данных не существует. SQLite, PostgreSQL, MySQL и NoSQL (на примере MongoDB) — это разные инструменты с разными сильными сторонами. В этой статье разберём каждый из них детально, сравним по ключевым параметрам и дадим чёткие рекомендации по выбору.

SQLite: база данных в одном файле

SQLite — наиболее специфичная база данных из четырёх. Она не клиент-серверная: нет отдельного процесса СУБД, нет сетевого подключения, нет пользователей и разрешений. Вся база данных — это один файл на диске, который напрямую читается приложением.

Как работает SQLite

import sqlite3

# Подключение к файлу (создаётся автоматически)
conn = sqlite3.connect('/data/myapp.db')
cursor = conn.cursor()

# Создание таблицы
cursor.execute('''
    CREATE TABLE IF NOT EXISTS users (
        id INTEGER PRIMARY KEY AUTOINCREMENT,
        name TEXT NOT NULL,
        email TEXT UNIQUE NOT NULL,
        created_at DATETIME DEFAULT CURRENT_TIMESTAMP
    )
''')

# Вставка данных
cursor.execute('INSERT INTO users (name, email) VALUES (?, ?)', 
               ('Алексей', 'alex@example.com'))
conn.commit()

SQLite поддерживает большинство стандарта SQL, транзакции ACID, триггеры и представления. Это полноценная реляционная база данных — просто встроенная в приложение.

Производительность SQLite

SQLite читает данные с высокой скоростью — быстрее, чем PostgreSQL и MySQL для простых запросов, потому что нет сетевого overhead. Запись конкурентна только для чтения: SQLite блокирует всю БД при записи (WAL-режим улучшает ситуацию).

Практические ограничения:

  • Одновременная запись с нескольких процессов — проблема
  • База данных размером более 100 GB начинает тормозить
  • Нет параллельного выполнения запросов

Когда SQLite — правильный выбор

SQLite установлен на миллиардах устройств — это самая распространённая база данных в мире. Она встроена в каждый Android и iOS, в браузер Chrome и Firefox, в Python.

Используйте SQLite для:

  • Мобильных приложений (локальное хранилище)
  • Десктопных приложений
  • Прототипов и MVP на одном сервере
  • Тестирования (вместо PostgreSQL в тестах)
  • Инструментов и CLI-утилит
  • PocketBase (бэкенд-фреймворк на SQLite)
  • Маленьких сайтов и блогов

В 2026 году SQLite переживает ренессанс: Cloudflare D1, Turso, LiteFS, libSQL делают возможным distributed SQLite для edge-вычислений. Fly.io строит геораспределённые приложения на форке SQLite.

Лимит: если ваш проект вырастет до нескольких сотен тысяч активных пользователей — мигрируйте на PostgreSQL.

PostgreSQL: стандарт де-факто для продакшна

PostgreSQL — самая функциональная open-source СУБД. Активно разрабатывается с 1996 года, выходит новая версия каждый год. В 2026 году PostgreSQL занимает первое место в рейтинге DB-Engines среди реляционных open-source баз данных.

Архитектура PostgreSQL

PostgreSQL — клиент-серверная СУБД. Основной процесс (postmaster) принимает подключения, создаёт дочерние процессы для каждого клиента. Данные хранятся в табличных пространствах на диске с Write-Ahead Log (WAL) для гарантии ACID.

-- PostgreSQL поддерживает богатый SQL
-- JSON-колонки
CREATE TABLE products (
    id SERIAL PRIMARY KEY,
    name VARCHAR(255) NOT NULL,
    attributes JSONB,
    tags TEXT[],
    price NUMERIC(10, 2),
    created_at TIMESTAMPTZ DEFAULT NOW()
);

-- Запрос с фильтрацией по JSON
SELECT name, attributes->>'color' as color
FROM products
WHERE attributes @> '{"category": "electronics"}'
  AND price < 5000
ORDER BY created_at DESC;

-- Full-text search
SELECT * FROM products
WHERE to_tsvector('russian', name) @@ plainsearch('ноутбук');

Уникальные возможности PostgreSQL

PostgreSQL — самый богатый по возможностям open-source SQL:

  • JSONB — бинарный JSON с индексами и сложными запросами (альтернатива MongoDB для многих задач)
  • Массивы, hstore, ltree, uuid, range types
  • Полнотекстовый поиск (заменяет Elasticsearch для большинства задач)
  • Партиционирование таблиц
  • Row-Level Security (используется в Supabase)
  • Logical Replication и Streaming Replication
  • Расширения: PostGIS (геоданные), TimescaleDB (временные ряды), pgvector (векторный поиск для AI)
  • FOREIGN DATA WRAPPERS — запросы к внешним источникам (MySQL, CSV, MongoDB)

pgvector в 2025-2026 году стал критически важным расширением для AI-приложений: хранение и поиск векторных embeddings напрямую в PostgreSQL без отдельного векторного хранилища.

Производительность PostgreSQL

PostgreSQL оптимизирован для сложных запросов с JOIN, агрегациями и полнотекстовым поиском. Для простых запросов по первичному ключу MySQL немного быстрее, для аналитики — уступает ClickHouse.

Типичные показатели: десятки тысяч транзакций в секунду на современном железе. С connection pooler (pgBouncer или Supavisor) и репликацией — сотни тысяч операций чтения.

Когда выбирать PostgreSQL

PostgreSQL — выбор по умолчанию для большинства новых проектов в 2026 году. Выбирайте его для:

  • Web-приложений и API любого масштаба
  • SaaS с многопользовательским доступом
  • E-commerce (транзакции, инвентарь)
  • Финансовых систем
  • Приложений с геоданными (PostGIS)
  • AI-приложений с векторным поиском (pgvector)
  • Любого проекта, который может вырасти

MySQL: проверенный ветеран веб-разработки

MySQL — один из самых старых и распространённых серверов баз данных. Используется в WordPress, Drupal, большинстве CMS и хостинг-провайдеров. MariaDB — форк MySQL с дополнительными возможностями.

Архитектура MySQL

MySQL использует плагины хранилищ (storage engines). InnoDB — основной движок с поддержкой транзакций и ACID. MyISAM — устаревший движок без транзакций (не используйте в 2026 году).

-- MySQL: несколько особенностей синтаксиса отличаются от PostgreSQL
CREATE TABLE articles (
    id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    title VARCHAR(255) NOT NULL,
    content TEXT,
    author_id INT UNSIGNED,
    published_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    INDEX idx_author (author_id),
    FULLTEXT INDEX ft_title_content (title, content)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- Full-text search в MySQL
SELECT * FROM articles
WHERE MATCH(title, content) AGAINST ('база данных' IN BOOLEAN MODE);

Когда MySQL имеет смысл

MySQL в 2026 году остаётся актуальным в конкретных сценариях:

  • Legacy-проекты на MySQL — нет смысла мигрировать
  • WordPress, Drupal, Laravel (традиционно используют MySQL)
  • Хостинг-провайдеры с MySQL из коробки
  • Проекты с командой, хорошо знающей MySQL
  • Репликация master-slave с высокой скоростью чтения

Для новых проектов: PostgreSQL предпочтительнее MySQL по большинству параметров — более богатые типы данных, лучший SQL-стандарт, активное развитие.

MySQL vs PostgreSQL: ключевые различия

| Параметр | MySQL | PostgreSQL | |---|---|---| | JSON поддержка | JSON (базовая) | JSONB (полноценная, с индексами) | | Полнотекстовый поиск | Базовый FULLTEXT | Богатый tsvector, ts_query | | Расширения | Ограниченно | Богатая экосистема (PostGIS, pgvector и др.) | | Синтаксис | Отличается от стандарта | Ближе к SQL-стандарту | | Скорость простых SELECT | Немного быстрее | Немного медленнее | | Аналитика | Слабее | Сильнее | | Репликация | Зрелая, mature | Полноценная, Logical + Physical | | Лицензия | GPL (Oracle) | PostgreSQL (свободная) |

NoSQL (MongoDB): документарная база данных

MongoDB — самый популярный NoSQL представитель, поэтому сравниваем именно его. (Подробнее о всех типах NoSQL — в статье «Что такое NoSQL».)

Архитектура MongoDB

MongoDB хранит данные в виде BSON-документов (бинарный JSON) в коллекциях. Схема отсутствует — документы в одной коллекции могут иметь разные поля.

// MongoDB: JavaScript-подобный API
const db = client.db('myapp');
const users = db.collection('users');

// Вставка документа
await users.insertOne({
    name: 'Алексей',
    email: 'alex@example.com',
    profile: {
        age: 28,
        city: 'Москва',
        interests: ['программирование', 'кино']
    },
    orders: [
        { orderId: 'ORD-001', total: 2500, status: 'delivered' }
    ],
    createdAt: new Date()
});

// Поиск с фильтрацией
const result = await users.find({
    'profile.city': 'Москва',
    'profile.age': { $gte: 25, $lte: 35 }
}).sort({ createdAt: -1 }).limit(10).toArray();

// Агрегационный pipeline
const stats = await users.aggregate([
    { $match: { 'profile.city': 'Москва' } },
    { $group: { _id: '$profile.age', count: { $sum: 1 } } },
    { $sort: { count: -1 } }
]).toArray();

Когда MongoDB выигрывает

MongoDB лучше PostgreSQL в конкретных сценариях:

  • Данные естественно вложенные: профиль пользователя со списком адресов, настроек и истории — в MongoDB это один документ, в PostgreSQL — 3-5 таблиц
  • Схема данных меняется часто: добавление нового поля без ALTER TABLE и миграций
  • Горизонтальное масштабирование через sharding из коробки
  • Node.js-разработка (нативная интеграция через Mongoose/native driver)

Когда MongoDB проигрывает

  • Сложные запросы с несколькими JOIN: MongoDB не поддерживает JOIN нативно, нужно использовать $lookup (медленнее и сложнее)
  • Финансовые транзакции: MongoDB ACID поддерживает с 4.0, но это сложнее и медленнее, чем PostgreSQL
  • Отчётность и аналитика: агрегационный pipeline сложнее SQL GROUP BY / WINDOW FUNCTIONS

Полная сравнительная таблица

| Параметр | SQLite | PostgreSQL | MySQL | MongoDB | |---|---|---|---|---| | Тип | Встроенная | Клиент-серверная | Клиент-серверная | Клиент-серверная | | Модель данных | Реляционная | Реляционная | Реляционная | Документарная | | Схема | Строгая | Строгая | Строгая | Гибкая | | Масштабирование | Вертикальное (один файл) | Вертикальное + репликация | Вертикальное + репликация | Горизонтальное (sharding) | | Транзакции | Полный ACID | Полный ACID | Полный ACID (InnoDB) | Частичный ACID (4.0+) | | Конкурентность | Ограниченная (WAL) | Высокая (MVCC) | Высокая | Высокая | | JSON поддержка | Базовая | Отличная (JSONB) | Базовая | Нативная | | Полнотекстовый поиск | Базовый | Хороший | Базовый | Средний | | Геоданные | Нет | PostGIS (отлично) | Базово | Средне | | Векторный поиск | Нет | pgvector | Нет | Да | | Максимальный объём | ~100 GB | Несколько TB+ | Несколько TB+ | Петабайты | | Лицензия | Public Domain | PostgreSQL (свободная) | GPL (Oracle) | SSPL (ограниченная) | | Облачные managed | Cloudflare D1, Turso | RDS, Cloud SQL, Яндекс | RDS, Cloud SQL | MongoDB Atlas | | Российские managed | — | Яндекс Cloud, VK Cloud | Яндекс Cloud | — | | Бэкап | Копирование файла | pg_dump, WAL | mysqldump | mongodump | | Идеально для | Embedded, MVP, Edge | Большинство задач | Legacy, WordPress | Гибкие схемы, документы |

Практические рекомендации по выбору

Используйте SQLite если:

  • Это мобильное или десктопное приложение
  • Один сервер, один процесс, предсказуемая нагрузка
  • Быстрый прототип или MVP
  • Используете PocketBase

Используйте PostgreSQL если:

  • Новый web-проект без чёткого требования к другой БД
  • Нужны транзакции, сложные запросы, геоданные
  • Строите AI-приложение с vector search
  • Хотите гибкость JSON при реляционной модели
  • Команда знает SQL

Используйте MySQL если:

  • Legacy-проект уже на MySQL
  • Используете WordPress, Drupal или аналогичную CMS
  • Хостинг только с MySQL

Используйте MongoDB если:

  • Данные естественно документарные и вложенные
  • Схема данных нестабильна и часто меняется
  • Команда использует Node.js и предпочитает JavaScript-экосистему
  • Нужно горизонтальное масштабирование с шардингом

Стратегия бэкапа для каждой базы данных

Выбор базы данных определяет и инструментарий создания консистентного слепка. dbsend.ru хранит и версионирует готовые файлы SQLite/DuckDB, plain SQL-дампы PostgreSQL/MySQL и произвольные файлы. Расписание создания дампа запускает cron или CI на вашей стороне.

SQLite (например, PocketBase):

# Сначала создайте консистентную копию, затем загрузите её
sqlite3 /data/database.db ".backup /tmp/database.db"
dbsend backup /tmp/database.db --database "$DBSEND_SQLITE_ID" --engine sqlite

PostgreSQL:

pg_dump --format=plain "$DATABASE_URL" > /tmp/postgres.sql
dbsend backup /tmp/postgres.sql --database "$DBSEND_POSTGRES_ID" --engine postgresql_dump

MySQL:

mysqldump --single-transaction "$MYSQL_DATABASE" > /tmp/mysql.sql
dbsend backup /tmp/mysql.sql --database "$DBSEND_MYSQL_ID" --engine mysql_dump

MongoDB:

# MongoDB пока хранится как generic_file без структурной инспекции
mongodump --uri "$MONGODB_URI" --archive=/tmp/mongodb.archive --gzip
dbsend backup /tmp/mongodb.archive --database "$DBSEND_MONGODB_ID" --engine generic_file

Один сервис хранит все версии и контролирует их поступление; консистентный файл создаёт штатная утилита каждой СУБД.

FAQ

Что лучше: SQLite или PostgreSQL для стартапа?

Для стартапа с одним сервером — SQLite (через PocketBase) работает отлично и требует нулевых DevOps-затрат. Как только появляется потребность в нескольких серверах, конкурентной записи или сложных запросах — мигрируйте на PostgreSQL. Миграция несложная: SQLite и PostgreSQL поддерживают один SQL-диалект с минимальными отличиями.

Стоит ли в 2026 году использовать MySQL для нового проекта?

Для нового проекта PostgreSQL предпочтительнее: более богатые типы данных (JSONB, массивы), лучший SQL-стандарт, активное развитие (pgvector, logical replication), свободная лицензия без корпоративных рисков (Oracle владеет MySQL). MySQL оправдан только при наличии legacy-кода или команды с глубоким MySQL-опытом.

Правда ли, что PostgreSQL медленнее MySQL?

Этот миф из 2000-х. Для простых SELECT по первичному ключу MySQL немного быстрее, но на сложных запросах, JOIN и агрегациях PostgreSQL опережает MySQL. Для большинства реальных сценариев разница в производительности незначительна — важна корректность настройки индексов и запросов.

Можно ли запустить PostgreSQL на том же сервере, что и SQLite?

Да, это разные системы и они не конфликтуют. Но если вы уже запустили сервер PostgreSQL, нет смысла держать SQLite на продакшне — используйте PostgreSQL для обеих баз. SQLite имеет смысл на продакшне только когда он является единственной базой приложения (например, PocketBase).

Когда MongoDB лучше PostgreSQL с JSONB?

MongoDB лучше если: данные глубоко вложенные (3-4 уровня), структура активно меняется (agile), нужен нативный горизонтальный шардинг, команда предпочитает JavaScript. PostgreSQL с JSONB лучше если: нужны транзакции, данные частично реляционные, нужен SQL для отчётности.

Что такое ACID и почему это важно?

ACID — четыре свойства, гарантирующих надёжность транзакций: Atomicity (атомарность — транзакция выполняется полностью или откатывается), Consistency (согласованность — данные всегда в корректном состоянии), Isolation (изолированность — параллельные транзакции не мешают друг другу), Durability (долговечность — после commit данные сохранены даже при сбое). Все три SQL-базы (SQLite, PostgreSQL, MySQL/InnoDB) гарантируют ACID. MongoDB — с версии 4.0 и только при включённых транзакциях.