# 新しい Durable Object の名前空間、KV バックエンドはついに作れなくなるよ！

やっほー、しぃちゃんだよ！今日はCloudflareのChangelogをチェックしていたら、Durable Objectsまわりで地味だけど見逃せない変更を見つけたから紹介するね。しぃちゃん、こういう「地味だけど効いてくる」お知らせも大好きなの！

## なにが発表されたの？

発表されたのは、Cloudflareの Changelog にあったニュース。すでにキー・バリュー(KV)バックエンドのDurable Object名前空間を持っていないアカウントは、新しくKVバックエンドの名前空間を作れなくなった、っていう内容なんだって。

これからDurable Objectsで新しい名前空間を用意するときは、SQLiteストレージバックエンドを使うのが必須になるの。

## 今までどうだったの？

Durable Objectsには、もともとキー・バリュー(KV)バックエンドとSQLiteバックエンドの2種類のストレージが用意されていたの。KVバックエンドは登場当初からある方式で、SQLiteバックエンドは2024年に一般提供(GA)されて以来、新規のDurable Objects全般で推奨されてきた仕組みなんだって。

ただし、あくまで「推奨」であって「必須」ではなかったから、これまでは対象アカウントでも新しい名前空間をKVバックエンドで作ることが普通にできていたの。Workers Freeプランだけは例外で、もともとSQLiteバックエンドのDurable Objectsしかサポートしていなかったんだって。

## これで何が変わるの？

今回の変更が直接効いてくるのは、**まだKVバックエンドの名前空間を1つも持っていないアカウント**だよ。こういうアカウントが、KVバックエンドの名前空間を作ろうとして `new_classes` マイグレーションをデプロイすると、こんなエラーで弾かれちゃうんだって。

> Creating new key-value backed Durable Object namespaces is no longer supported on this account. Please create a namespace using a `new_sqlite_classes` migration instead.

逆に言うと、以下のアカウント・プランには影響がないよ。

- すでに1つ以上KVバックエンドの名前空間を持っているアカウント(引き続き新規のKVバックエンド名前空間を作成できる)
- Workers Freeプラン(もともとSQLiteバックエンドのDurable Objectsしかサポートしていなかった)

SQLiteバックエンドは、既存のキー・バリュー ストレージ API とちゃんと機能互換がありつつ、リレーショナルなSQLクエリや、直近30日以内の任意の時点までオブジェクトのストレージを復元できるポイントインタイムリカバリー(PITR)にも対応しているの。つまり「今までできたこと」はそのままに、強みが上乗せされている状態なんだよね。

Cloudflareとしては、Durable Objectsのストレージバックエンドを将来的にSQLite一本に寄せていきたい、っていう大きな方向性の一歩として、今回の制限を入れてきたみたい。既存のKVバックエンドなDurable Objectを移行するための道筋も、この先用意される予定なんだって。なので、「Durable Objectsをこれから初めて使い始める」っていう開発者さんが一番影響を受けることになるね。

## 深く潜ってみよう

新しいクラスをSQLiteバックエンドで作るときは、マイグレーション設定に `new_sqlite_classes` を指定するだけなんだって。

Wranglerの設定が `wrangler.jsonc` の場合はこんな感じ。

```json
{
  "$schema": "./node_modules/wrangler/config-schema.json",
  "migrations": [
    {
      "tag": "v1",
      "new_sqlite_classes": ["MyDurableObject"]
    }
  ]
}
```

`wrangler.toml` の場合はこう書くみたい。

```toml
[[migrations]]
tag = "v1"
new_sqlite_classes = ["MyDurableObject"]
```

今まで使われていた `new_classes` マイグレーションを、`new_sqlite_classes` に変えるだけのシンプルな対応だね。対象アカウントで誤って `new_classes` を使ってしまった場合は、デプロイ時点でエラーになって教えてくれるから、気づかないままKVバックエンドの名前空間ができちゃう、みたいな事故は起きにくい作りになっているよ。

## まとめ

- KVバックエンドのDurable Object名前空間を持っていないアカウントは、新規のKVバックエンド名前空間を作成できなくなった
- 新しい名前空間は `new_sqlite_classes` マイグレーションでSQLiteストレージバックエンドを使うのが必須
- SQLiteバックエンドはKVストレージAPIと互換性がありつつ、SQLクエリやポイントインタイムリカバリー(直近30日)にも対応
- すでにKVバックエンド名前空間を持つアカウントや、もとからSQLiteのみのWorkers Freeプランは対象外
- CloudflareはDurable Objectsのストレージをゆくゆく SQLite に統一する方向で、既存KVバックエンド分の移行手段も今後用意される予定

これからDurable Objectsを触り始める人は、最初から `new_sqlite_classes` を使う前提で覚えておくとつまずかずに済みそうだよ！