SQLite: коли його достатньо
Де SQLite на VPS кращий за окремий сервер бази даних, як увімкнути WAL і уникнути «database is locked», і коли настав час переходити на PostgreSQL.
Оновлено 23 серпня 2026 р.
SQLite — це база даних в одному файлі: без служби, без порту, без пароля. Для бота, невеликої панелі або сайту з нечастими записами це правильний вибір: вона не з'їдає пам'ять, а у VDS-1 її лише 2 ГБ, і налаштовувати нічого не потрібно.
Коли використовувати
Добре підходить:
- боти для Telegram і Discord, лічильники, налаштування;
- сайти з тисячами читань і десятками записів за хвилину;
- будь-який проєкт на одній машині без планів на другий сервер.
Не підходить:
- кілька процесів, які активно пишуть одночасно;
- база даних розміром понад кілька десятків гігабайтів;
- мережевий доступ з іншої машини — SQLite цього просто не вміє.
У другому й третьому випадках використовуйте PostgreSQL або MySQL.
Робота з файлом
apt install -y sqlite3
sqlite3 /srv/app/data/app.db
CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT NOT NULL);
INSERT INTO users (name) VALUES ('test');
.tables
.schema users
.quit
Файл бази даних має лежати на локальному диску машини й належати користувачу застосунку:
chown appuser:appuser /srv/app/data/app.db
chmod 640 /srv/app/data/app.db
Каталог із базою даних також має бути доступним для запису: SQLite створює поруч тимчасові файли -wal і -shm.
Обов'язкові налаштування
Два налаштування pragma усувають більшість проблем:
PRAGMA journal_mode = WAL;
PRAGMA busy_timeout = 5000;
WAL дає змогу читачам читати під час запису — без нього будь-який читач блокується тим, хто пише. busy_timeout змушує клієнт чекати п'ять секунд замість негайної помилки. Задавайте їх щоразу під час відкриття з'єднання в коді, а не один раз у консолі.
Резервні копії
Не можна копіювати файл звичайним cp, поки застосунок працює, — отримаєте пошкоджену базу даних. Є вбудована безпечна команда:
sqlite3 /srv/app/data/app.db ".backup '/srv/backups/app-$(date +%F).db'"
Додайте її в cron і переносьте копію за межі машини: у VPS немає ні автоматичних резервних копій, ні знімків. Загальний підхід описано в резервне копіювання баз даних.
Типові помилки
| Симптом | Причина |
|---|---|
database is locked | Немає WAL або busy_timeout, або другий процес тримає довгу транзакцію |
attempt to write a readonly database | Немає прав на файл або каталог |
disk I/O error | Замало місця на диску — перевірте індикатор використання диска в розділі «Огляд» |
| База даних зростає після видалення рядків | Місце не звільняється автоматично: VACUUM |
| Пошкоджена база даних після копіювання | Ви копіювали через cp під час роботи — використовуйте лише .backup |
Коли переходити
Ознаки: регулярні помилки database is locked навіть із увімкненим WAL, кілька робочих процесів застосунку, звіти, що обчислюються хвилинами. Щоб перейти, дивіться міграцію бази даних.
Файл бази даних не повинен лежати в каталозі, який роздає вебсервер.
/var/www/app.dbможна завантажити за прямим посиланням разом з усіма паролями й даними користувачів.