Turso libSQL vs Cloudflare D1
Astro モノレポのデータベース選びは、ワークフロー次第です。
最近、3つの Astro SSG サイト向けに共有データベースを構築しました。選択肢は Turso (libSQL) か Cloudflare D1 の2つでした。
私は Turso を選びました。
実用的な違いがなぜ重要だったのか、その理由を説明します。
Cloudflare D1 は Cloudflare Workers 用に構築されています。サーバーサイドレンダリングに Workers を使用しているなら、D1 が最適です。コードが実行される場所にデータベースが存在するからです。
私の構成は異なります。サイトは Cloudflare Pages 上で動作する静的な Astro 5 SSG です。Workers は使用していません。ETL パイプラインは GitHub Actions で実行されます。
GitHub Actions から D1 を使用するのは困難です。Cloudflare API または Wrangler CLI を使用する必要がありますが、どちらも開発中にクエリを実行するためのローカルな SQLite ファイルを提供してくれません。結局、テストのたびにリモートデータベースにアクセスすることになります。
Turso は @libsql/client パッケージでこの問題を解決します。このパッケージは URL を受け入れますが、その URL はリモートのリンクでもローカルのファイルパスでも構いません。
コードは以下のようになります：
CI では、URL はリモートの Turso リンクになります。 ノートPC上では、クライアントがローカルファイルを開きます。 パッケージ、クエリ、スキーマはすべて同じです。
コードのパスは全く同一です。
これにより、以下のことが可能になります：
- ETL スクリプトをローカルで実行する。
- あらゆる SQLite ビューアでデータベースを検査する。
- 本番環境で使用するのと同じ関数でマイグレーションを実行する。
Docker も特別なフラグも必要ありません。同じ SQL がどこでも動作します。
マイグレーションには冪等（べきとう）なアプローチを採用しています。コード内でテーブルの存在を確認してから作成するため、繰り返し実行しても安全です。
どのような場合に D1 を選ぶべきでしょうか？ 検索や API ルートに Cloudflare Workers を使用している場合は、D1 の方が優れています。同じデータセンター内に留まるため、接続が高速だからです。
私のアーキテクチャは完全に静的です。Workers を使用していないため、D1 の最大の利点が失われてしまいます。
現在のトレードオフ：
- 書き込みパフォーマンス：ETL はタスクを一つずつ実行します。高速な並列書き込みについてはテストしていません。
- スキーマ変更：カラムの追加は簡単ですが、カラム名の変更にはより注意が必要です。
- 価格：どちらも寛大な無料枠があります。3つのサイトの場合、コストはゼロです。
データベースの選択自体が主な目的ではありませんでした。ローカルファイルへのフォールバックができることが、私が Turso を選んだ理由です。それによって開発がシンプルになります。