Hacker News Digest

Rails + SQLite: новые способы уронить прод

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

Правило 1: клади БД в персистентное хранилище (EBS, Fly Volumes, …) и включи снапшоты.

Правило 2: веб, кеш, очередь и джобы по умолчанию пишут в тот же файл. Удобно, но воркеры теперь должны видеть этот файл. Запускай воркеры в том же VM, либо разнеси данные по разным БД и настрой database.yml.

Правило 3: SQLite блокирует всю БД на время записи. Параллельные длинные запросы = таймауты. Держи транзакции короткими, используй PRAGMA journal_mode=WAL, synchronous=NORMAL, busy_timeout=5000.

Правило 4: бекапы. sqlite3 db.sqlite3 ".backup backup.sqlite3" — атомарно, без остановки сервиса. Крути каждый час и перед деплоем.

Плюсы:

• FTS5-индекс из коробки
• Мегабайты вместо гигабайтов RAM
• $14/мес на Fly.io при 1 млн запросов
• Нет Redis, Postgres, S3 — только Rails-контейнер

Итог: SQLite позволяет поднять pet-project за вечер, но требует новых привычек: персистентные диски, WAL, короткие транзакции, общий доступ к файлу. Соблюдай правила — и база не уйдёт в /dev/null.

• Автор статьи утверждает, что его сервис «Feed Your Email» возможен только благодаря SQLite, но не объясняет, почему именно SQLite, а не PostgreSQL/MySQL.
• Многие участники считают SQLite удобным для малонагруженных и внутренних приложений из-за простоты развёртывания и отсутствия отдельного процесса БД.
• Критики отмечают: при росте нагрузки появляются проблемы с бэкапами, масштабированием, единственным писателем и отказоустойчивостью, смывая преимущества.
• Часть разработчиков использует обёртки вроде Litestream, Turso или Cloudflare D1, чтобы добавить репликацию и горизонтальное масштабирование к SQLite.
• В сообществе Rails новый тренд — «по-умолчанию SQLite» для быстрого старта MVP, но опытные пользователи предупреждают о риске «выстрелить себе в ногу» при росте проекта.

• EC2

  • Менять IAM-роли и security-groups можно без остановки инстанса.
  • EBS можно расширять, подключать и отключать «на горячую».
  • Принудительный stop/terminate без ожидания таймаута.
  • Live-migration между хостами почти убрала деградацию инстансов.
  • Надёжность выросла: «исчезновение» инстансов стало редкостью.
  • Spot-рынок стал стабильнее, без аукционов.
  • Dedicated Instances почти не нужны — даже для HIPAA.
  • AMI Block Public Access включён по умолчанию.

• S3

  • Стал строго согласованным (read-after-write).
  • Не нужно рандомить префиксы ключей для равномерного распределения.
  • ACL устарели и отключены по умолчанию.
  • Block Public Access включён на новых бакетах.
  • Шифрование покоя включено по умолчанию.

• AWS теперь по умолчанию блокирует публичный доступ к новым S3-бакетам; это снижает утечки, но усложняет легитимное открытие доступа.
• Пользователи обсуждают, что многие «улучшения» AWS — это просто исправление первоначально неудобных решений, и это влияет на репутацию.
• По-прежнему спорны детали: нужно ли случайное префиксирование ключей S3, почему NAT Gateway взимается за трафик внутри одного региона и почему Transit Gateway дороже peering.
• Некоторые разработчели «деградируют» от сложных serverless-стеков к простым EC2 + S3 + Route 53 ради простоты и экономии времени на IAM.
• Участники просят ежегодные сводки изменений и жалуются на ослабление платной поддержки AWS.