раздел 05 · подстраница 3

Серверные и облачные БД

SQLite живёт в файле на одной машине. Как только данными должны пользоваться много людей с разных устройств одновременно, базе нужен собственный дом - отдельная программа-сервер, к которой по сети подключаются все остальные. Разберём, когда это нужно и что выбрать.

Чем серверная база отличается от файла

SQLite - это библиотека внутри вашей программы. PostgreSQL и MySQL - отдельные программы (серверы), которые работают всё время и принимают подключения по сети.

| | SQLite | Серверная БД (Postgres) | | --- | --- | --- | | Где живёт | файл рядом с приложением | отдельный сервер | | Доступ | одна машина | много клиентов по сети | | Одновременная запись | ограниченно | для этого и создана | | Настройка | ноль | нужно поднять и настроить | | Когда брать | прототип, один сервер | прод с пользователями |

Когда пора уходить с SQLite

  • К базе обращаются несколько серверов или сервисов сразу.
  • Много одновременных записей от разных пользователей.
  • Данных стало действительно много (миллионы записей) и нужна серьёзная производительность.
  • Нужны вещи уровня прод: репликация, резервное копирование на лету, тонкие права доступа.

PostgreSQL и MySQL

Две самые популярные серверные SQL-базы.

PostgreSQL - выбор по умолчанию в 2026 году. Мощный, надёжный, отлично работает со сложными запросами, умеет хранить JSON прямо в столбцах. Если сомневаетесь - берите его.

MySQL - проще, исторически популярен, особенно в связке с PHP и старыми проектами. Для нового проекта обычно берут Postgres.

SQL у них почти такой же, как вы учили на SQLite, - навык переносится напрямую. Разница в установке, настройке и подключении (адрес сервера, порт, логин, пароль).

Облачные базы: база без возни с сервером

Поднимать и обслуживать сервер базы вручную - отдельная работа. Облачные сервисы берут это на себя: вы получаете готовую базу по ссылке, а они занимаются серверами, бэкапами и обновлениями.

Supabase - PostgreSQL в облаке плюс готовые API, авторизация и хранилище файлов. Очень дружелюбен к вайб-кодингу: завели проект, получили базу и автоматический REST/JS-доступ к ней. Под капотом - обычный Postgres, никакого вендор-лока на уровне SQL.

Firebase (Firestore) - облачная база от Google, но другого, NoSQL-типа: данные хранятся как JSON-документы, без жёстких таблиц. Сильна в реалтайме (данные сами обновляются у всех клиентов) и в мобильных приложениях. Минус - своя модель, навыки SQL тут не применить напрямую.

Прочие - PlanetScale (MySQL), Neon (Postgres), MongoDB Atlas (NoSQL-документы). Все решают одну задачу: дать базу без ручного администрирования сервера.

SQL или NoSQL: короткий ответ

  • SQL (Postgres, Supabase, MySQL) - данные структурированы, есть связи, нужны надёжность и сложные запросы. Это 80% проектов. Выбор по умолчанию.
  • NoSQL (Firebase, MongoDB) - структура заранее не фиксирована, данные как документы, нужен реалтайм или экстремальный масштаб. Берите осознанно, под конкретную причину.

Что выбрать для старта

Практичный маршрут для вайб-кодера:

  1. Прототип на ноутбуке - SQLite.
  2. Нужен сайт/приложение с пользователями и без возни с сервером - Supabase (тот же Postgres, но в облаке и с готовым API).
  3. Свой сервер и контроль над всем - PostgreSQL на вашем VPS.
  4. Мобильное приложение с реалтаймом - присмотритесь к Firebase.

Антипаттерны

  • Поднимать PostgreSQL-кластер ради todo-списка. Сложность без причины. Начните с SQLite или Supabase.
  • Хранить пароль от базы в коде и коммитить в git. Доступы держат в переменных окружения (.env), который не попадает в репозиторий.
  • Выбирать NoSQL «потому что модно». Без конкретной причины (реалтайм, документы, масштаб) реляционная база почти всегда удобнее.