раздел 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) - структура заранее не фиксирована, данные как документы, нужен реалтайм или экстремальный масштаб. Берите осознанно, под конкретную причину.
Что выбрать для старта
Практичный маршрут для вайб-кодера:
- Прототип на ноутбуке - SQLite.
- Нужен сайт/приложение с пользователями и без возни с сервером - Supabase (тот же Postgres, но в облаке и с готовым API).
- Свой сервер и контроль над всем - PostgreSQL на вашем VPS.
- Мобильное приложение с реалтаймом - присмотритесь к Firebase.
Антипаттерны
- Поднимать PostgreSQL-кластер ради todo-списка. Сложность без причины. Начните с SQLite или Supabase.
- Хранить пароль от базы в коде и коммитить в git. Доступы держат в переменных окружения (
.env), который не попадает в репозиторий. - Выбирать NoSQL «потому что модно». Без конкретной причины (реалтайм, документы, масштаб) реляционная база почти всегда удобнее.