150 MB のサイズ上限
すべてのプランに同じデータベースの容量上限を適用します。バックアップ性能を維持するための上限です。
プロジェクトのデータベースの運用上の容量上限は、プランに関係なく 150 MB です。
上限を設けている理由
エンジン自体はもっと大きなデータベースも扱えます。しかし現在の方式で 420 MB のデータベースをバックアップすると 107 秒かかり、4.57 GB のメモリを使います。その間、そのプロジェクトのデータベースリクエストは待機することになります。
毎時のバックアップを提供するには、1 回のバックアップのコストが許容できる水準に収まっている必要があります。そのため現在は、その条件を満たす地点として 150 MB の上限を設けています。
変更されたデータだけをバックアップする増分方式が導入されれば、この上限は引き上げられます。
行数で見積もらないでください
インデックスとページのオーバーヘッドが元データより大きくなります。実測の一例: 61,000 行 (JSON で 5.5 MB) がインデックス 9 個と合わせて 80 MB を使いました。元サイズの 10〜15 倍を見込み、投入後に runlot usage で確認してください。
現在の使用量を確認する
runlot usageダッシュボードのデータベースタブでも同じ値を確認できます。
他のサービスとの比較
現在の容量上限は、他のサービスの無料提供量より小さい値です。
| サービス | 容量 |
|---|---|
| runlot | 150 MB（全プラン） |
| Cloudflare D1 | 無料 5 GB |
| Supabase | 無料 約 500 MB |
その代わりデータベースはアプリと同じマシンで動くため、env.db の呼び出しにネットワークの往復はありません。この設計は、サイドプロジェクトにおいて大容量データよりも速い応答を優先しています。
上限に近づいたら
容量の 90% に達すると、組織の admin に db_near_cap の通知を送ります。上限を超えた後ではなく、事前に対応できるようにお知らせします。
現在、上限で書き込みを拒否することはありません。代わりに 2 つのことが悪化します。1 時間ごとのバックアップがサイズに比例して長くなり、およそ 240MB を超えると、コールドになったプロジェクトが復帰できないことがあります (restore_too_large)。150MB は私たちがサポートするサイズであって、超えたら止めてくれる壁ではありません。
画像や添付ファイルのような大きなバイナリデータは、データベースではなくファイルストレージに保存してください。無料ティアで 1 GiB を提供しています。