個人開発で一部DBとして使用しているContentfulをSupabaseに移行した

個人開発で運営しているWebサービスの一部DBとして使用しているContentfulをSupabaseに移行した話をまとめました。

個人開発のWebサービスをContentfulからSupabaseに移行した経緯

Contentfulの無料枠で使用しているのですが、無料枠だとレコード数が1万件となっており、徐々に上限に近づいていました。このままだと半年後くらいに上限にいきそうだったので、移行することにしました。

ちなみに有料プランも考えたのですが、1ヶ月300ドルと高いのとレコード数の上限が5万件といずれまた上限に達する時がきてしまうのと思ったのでやめました。

Contentfulからのデータを取得する際にAPI経由で取得するのですが、Contentfulが指定した条件で取得するため、若干使いづらいところがありました。

具体的に全文検索でmatchを使うのですが、データによってはヒットするはずなのに引っかからなかったりしていました。今後、Webサービスの検索性を高めるためにも移行しておきたかったです。

今後WebサービスとしてCGM要素が追加されることもあり、ContentfulのAPIにGETだけでなくPOSTやUPDATEのリクエストを頻繁に行われることになります。

初期の頃の静的なコンテンツメインの情報サイトからCGMサービスとして変化していく中で、今後もContentfulを使っていくことに違和感を感じ、ちゃんと自前でDBを用意してあげる方が今後の保守性や拡張性においても良いのではないかと思いました。

Contentfulを使っていたことからサーバレスのアプリケーション構造になっており、その構造でも導入できるSupabaseを選択しました。

またSupabaseにした理由として、RDBが使いたかったのとライブラリが用意され触った感じ使いやすかったためです。SupabaseのDBはPostgreSQLを使用しており、ライブラリのドキュメントも充実していました。

まずSupabaseで開発環境と本番環境を構築しました。アカウント登録してプロジェクト作成しました。

Build production-grade applications with…

supabase.com

次にWebアプリケーション内のソースコードを新しくSupabaseの接続用に作成しました。

Supabase用のDriverを用意して、ローカル環境で向き先をSupabaseにして実装をしました。

ContentfulにあるデータをSupabaseのDBに移行しました。ContentfulからデータをGETしてSupabaseのDBにINSERTするスクリプトを書いて、そのスクリプトを実行することでデータ移行しました。

ローカル環境での開発が終わったら、実際に検証環境にあげて本番環境と同じ動作になるかを検証しました。

検証環境の動作確認を終えて、問題ないことを確認した後、本番環境への移行作業を行いました。

やはり人力の動作確認やテストだとどうしても抜け漏れがあり、本番移行後に気づいたバグがいくつかありました。今後バグを発生させないようにするためにもE2Eの導入などが必要になりそうです。

とんとん拍子でいけると思ったら、実際に修正するコードが多かったり、データ移行にハマったりと思ったよりも時間がかかりました。事前に調査してたとはいえ、移行作業はどうしても読めないことが多く、時間がかかってしまうなと改めて感じました。