Limitations

SQLite отличен в своих границах. За их пределами боль от конкуренции, среды деплоя и масштаба — а не от «нехватки SQL» для большинства приложений.

| Ограничение | Практическое влияние | |-------------|----------------------| | Один writer | Много concurrent writers в очереди; WAL помогает читателям | | Сетевые ФС | Риск порчи из-за блокировок — только локальный диск | | Нет встроенного HA | Репликация на уровне приложения (LiteFS, rqlite) или export | | Скромный ops tooling | Нет ролей, нет server-side connection pooling | | Type affinity | Гибкая типизация скрывает баги без strict mode |

					PRAGMA journal_mode = WAL;   -- читатели меньше блокируют writer
PRAGMA synchronous = NORMAL; -- баланс durability и скорости (знайте риск)
PRAGMA busy_timeout = 5000;  -- ждать lock вместо мгновенного SQLITE_BUSY
				

Обрабатывайте `SQLITE_BUSY` повторами и короткими транзакциями. Для multi-instance backend с тяжёлой записью безопаснее PostgreSQL или MySQL.

На интервью: правило single-writer; предупреждение про NFS; когда откажетесь от SQLite для backend-сервиса.

Типовые ошибки: несколько app servers пишут в один файл; Docker volume на сетевом storage; type affinity без валидации; backup без учёта блокировок приложения.

Компромисс — радикальная простота для embedded и edge против жёсткого потолка параллелизма записи и централизованной эксплуатации.

Чеклист:

• Подтвердите single-writer или примите retry/backoff.
• Файлы БД — на локальной ФС.
• WAL, busy_timeout и стратегия backup.
• Пересмотр при росте write QPS или требований HA.