はじめに
フロントエンドを Next.js で、 バックエンドを NestJS で個人開発をしている中で、 NestJS のチュートリアルを見ていたら、 DB には Neon の Postgres を使うよと出てきました。
でもフロントを Next.js で作っているし、どうせなら Vercel Postgres を試したいなと思い調べたところ、実は Vercel Postgres の裏側では Neon Postgres が動いている（powered by Neon）ということがわかりました。
そこで、じゃあ結局どっち使ったほうがええねん、ということでメリデメをまとめてみます。
筆者が個人開発のための選定の際に調べた情報をまとめている記事となっております。実際に選定する際には一次情報をご確認ください。
まずは気になるお値段
個人開発なので無料でどこまで使えるのか？を見ていきます。
Neon は Free プラン、 Vercel Postgres は Hobby プランを使うことである程度の機能を無料で使えそうです。
以下に無料で使える機能を表としてまとめてみました。
各機能の制限でいうと Neon のほうが圧倒的に無料枠での機能制限がゆるいことがわかります。
| 機能 | Neon | Vercel Postgres |
|---|---|---|
| プロジェクト数 | 1つまで | N/A ※1 |
| DB数 | 無制限 | 1つまで |
| データ書き込み | 無制限 | N/A ※2 |
| データ転送 | 無制限 | N/A ※2 |
| Compute Time | 100 時間/月 | 60 時間/月 |
| Storage | 3GiB ※3 | 256MB |
| DBブランチ数 ※4 | 10個 | 1個 |
| Compute Size | 0.25 vCPU, 1 GB RAM | 0.25 vCPU, 1 GB RAM |
※1: Vercel Postgres 自体にプロジェクトという概念はなく、作成した DB をプロジェクトに紐付けるという形になるため N/A。
※2：ドキュメントではもともと 256MB/月だったのが n/a になっていたのでおそらく無制限になった。
※3: ブランチごとの Storage。
※4: Neon にはデータベースブランチングという、 git でコードをブランチングするように、データをブランチングできる機能があります。後述しますが、 Vercel ではそもそもこの機能を使えない(メインブランチの1つのみ)のため、 1 個としてあります。
使用可能なリージョン
それぞれ記載のリージョンの所在地は多少異なりますが、大まかには同じような位置にあるようです。
Neon のほうではイスラエルのリージョンが使えるようですが、日本で利用することを想定としているため大きなメリットにはならなそうです。
| region | Neon | Vercel Postgres |
|---|---|---|
| us-east-1 | N. Virginia | Washington, D.C., USA |
| us-east-2 | Ohio | Cleveland, USA |
| us-west-2 | Oregon | Portland, USA |
| eu-central-1 | Frankfurt | Frankfurt, Germany |
| ap-southeast-1 | Singapore | Singapore |
| ap-southeast-2 | Sydney | Sydney, Australia |
| il-central-1 | Tel Aviv, Israel | N/A |
ただし以下の記事を読む限り、 Neon は近い将来に日本のリージョンを使えるようにすることも考えているとのことでした。
そもそもなんで Vercel Postgres があるのか？
Neon のほうが安いんだし、高機能だし、要らなくね？とココまでは思っています。したがって、両者の見解を少しみてみます。
Vercel の見解
上記の Vercel 公式ドキュメントを読むと、
V「おまいらがアプリ開発に集中できるように、適切なレベルの抽象化をしとるんや！」
V「より高度な機能を使いたかったら Neon の Integration を使ってくれよな！」
(意訳)
的なことが書かれていました。DBまわりに疎い筆者はあまりパッとしませんでした。
Neon の見解
では次に上記の Neon 側の見解を読んでみます。
N「Vercel Postgres は、 Neon Console/API じゃなくて Vercel ダッシュボードでポスグレインスタンスを管理できるし、 Neon アカウントを作る必要すらないやで。」
N「Vercel Postgres は、 Neon Integration を介さずに Vercel から直接 Neon をいじれる代替手段なんや！」
(意訳)
というわけで、 Neon さんの「もともと Integration を介してたのが直接 Vercel から触れるようになった！」という主張と、 Vercel くんの「抽象化したけど、高度な使い方したいなら Integration つこてくれよな！」という２つの主張があることがわかりました。
Vercel Postgres で使えない Neon の機能
Vercel のいう「抽象化」を行った結果なのかわかりませんが、 Vercel Postgres では使えない Neon の機能がいくつかあるようなので、そちらを見ていきます。
- Neon のウェブコンソールにアクセスできない
- データベースブランチングはサポートしていない（将来的にはサポート予定）
- Postgres access role （ユーザーのようなもの）を複数設定できない
どれも小/中規模の個人開発レベルではあまり気にならないデメリットかもしれません。
Vercel Postgres の強み？
次に、 Neon ではなく Vercel Postgres を使うことによるメリットを考えてみましたが、個人的な感想レベルで以下2つしか思いつきませんでした。
- 前述したように抽象化していたり、 Vercel ダッシュボードで他のサービスと並べて管理・課金などできるので、 Vercel をガッツリ使うのであれば考えることが減って楽
- Vercel サービスとの親和性が高い、もしくは高くなっていく？（予想）
一応、 @vercel/postgres という SDK が提供されてはいるのですが、結局 postgres パッケージや ORM などを使用すれば不要なものなので、あまり大きな強みにはならないと思います。
結論
調査不足感が否めないですが、小/中規模の個人開発レベルかつ、 Vercel 大好き！とかでなければ、いったん Neon を使うほうが安くそこそこの機能が使えるので良いと思います。