Supabase vs Neon｜Netlifyで静的サイト運用で見えた「使い分け」の結論

こんにちは、Hodaです。

僕は今まで主に Vercel か Netlify でサイトを運用してきました。そして、データベースは常に Supabase を使って管理してきました。

Supabaseを使うことで、認証もストレージも込みで一つにまとまる安心感があり、正直「困ったらとりあえずSupabase」で十分だと思っていたタイプです。

ただ、Netlify上でAstroやHugoの静的サイトをビルドする用途に限って言うと、Neon だけで十分に事足りるケースが多いことに気づき、今ではいくつかのサイトでNeonを併用するようになりました。

この記事では「どちらが優れているか」ではなく、用途によって向き不向きがはっきり分かれる という前提で、SupabaseとNeonの違いを整理していきます。どちらも良いサービスなので、自分のプロジェクトに当てはめて読んでもらえればと思います。

そもそもの立ち位置が違う

まず前提として、SupabaseとNeonは「同じPostgres系サービス」という括りで比較されがちですが、目指しているものが根本的に違います。

• Supabase：Postgresを中核に、認証（Auth）・ファイルストレージ・リアルタイム更新・Edge Functionsまでセットにした、いわゆるオールインワンのバックエンド基盤（Firebase的な立ち位置）
• Neon：認証やストレージは持たず、Postgresというデータベースそのものの使い勝手・コスト効率・開発体験を突き詰めたサービス

つまり「Webアプリのバックエンドを丸ごと任せたいか」「純粋にデータベースだけが欲しいか」で、最初から住み分けができているとも言えます。

Netlify × 静的サイト（Astro/Hugo）で見えた違い

AstroやHugoでビルドした静的サイトをNetlifyでホスティングしている場合、DBへのアクセスは基本的にビルド時（またはコンテンツ更新時）だけです。常時アクセスが発生するWebアプリとは前提が異なります。動的なデータを扱うわけではなく、あくまでも静的なサイトがメインですからね。

この用途で特に効いてくるのが、次の2点でした。

1. 使っていない時間はコンピュートが自動停止する（Scale to Zero）
Neonはアクセスがない時間帯、DBのコンピュートが自動的にスリープします。ビルド時しかアクセスしないなら、実質ほとんどの時間は課金対象外になるイメージです。

2. プロジェクト課金ではなく、アカウント単位の従量課金
ここがSupabaseとの一番の違いだと感じています。Supabaseは基本的に「プロジェクトごと」に有料プランが必要になるため、案件ごとに小さいサイトを量産していると、その分だけ費用がかさみます。一方Neonの有料プランは、1つの契約で複数プロジェクトをまとめて運用でき、かかった分だけ支払う形なので、サイドプロジェクトや複数クライアントの静的サイトを並行運用するスタイルとの相性が良いです。

例えば、プロジェクトを5個運用している場合、Supabaseの場合はそれぞれのプロジェクトに対して有料プランが必要になりますが、Neonの場合は1つの契約で複数プロジェクトをまとめて運用できるため、費用を節約することができます。

また、Netlify自身のDB機能の裏側がNeonで構築されているという背景もあり、Netlifyでの静的ビルド用途とは元々親和性が高い組み合わせだと言えます。

料金プランの違い

無料プランでどこまでできるか、有料プランにした時に何が変わるかも、実際に選ぶ上では気になるところだと思うので整理しておきます。

※料金・容量は両サービスとも改定されることがあるので、最終的には必ず公式サイトの最新情報を確認してください。

無料プランでできること

テキストデータ中心の静的サイト用途であれば、どちらの無料プランでもしばらくは十分に運用できます。違いが出てくるのは「案件数が増えて有料化を検討するタイミング」です。

有料プランにした時の違い（ここが一番の分かれ目）

• Supabase：有料プランは基本的にプロジェクト単位の契約です。Proプラン（月額$25〜）にする場合、プロジェクトを5つ運用していれば、その5つぶん契約が必要になります。案件が増えるほど、費用も比例して増えていくイメージです。
• Neon：有料プラン（Launchプランなど）はアカウント単位の従量課金です。1つの契約の中で最大100プロジェクトまで作成でき、コンピュート時間とストレージ量に応じて課金される仕組みなので、「5プロジェクトあるから5契約」にはなりません。ビルド時しかDBに触らない静的サイトなら、複数プロジェクトをまとめても月額が数ドル〜十数ドル程度に収まることも珍しくありません。

つまり、静的サイトを何本も並行運用しているような使い方だと、Supabaseは「プロジェクト数×固定費」、Neonは「実際に使った分だけ」という、課金の伸び方そのものが変わってきます。逆に言うと、DBに常時アクセスがあるような本格的なWebアプリを1〜2個だけ運用するなら、この差はそこまで大きく効いてこないケースもあります。

基本的なコマンドを触ってみる

どちらもCLIやクライアントライブラリからサクッと扱えるので、簡単な例だけ載せておきます。

Neon

ブランチの作成・接続文字列の取得・削除まで、CLIだけで完結します。

# mainブランチから新しいブランチを作成
neon branches create --name preview --parent main

# 作成したブランチの接続文字列を取得
neon connection-string preview

# 使い終わったブランチを削除
neon branches delete preview

ビルドスクリプト側からは、Postgresクライアントでそのまま接続してデータを取得するだけです。

import { neon } from '@neondatabase/serverless';

const sql = neon(process.env.DATABASE_URL);
const posts = await sql`SELECT * FROM posts WHERE published = true`;

Supabase

ローカル環境の起動からマイグレーションの反映まで、こちらもCLIで一通り行えます。

# プロジェクトの初期化
supabase init

# ローカル環境を起動
supabase start

# スキーマ変更をリモートDBに反映
supabase db push

データ取得はsupabase-jsを使うのが基本です。

import { createClient } from '@supabase/supabase-js';

const supabase = createClient(supabaseUrl, supabaseAnonKey);
const { data: posts } = await supabase
  .from('posts')
  .select('*')
  .eq('published', true);

ビルド時に一括取得してAstro/Hugoに流し込むだけなら、どちらも数行のコードで完結する点は共通しています。

用途別のメリット・デメリット

Neonが向いているケース

Supabaseが向いているケース

実際に運用してみて感じたこと

まとめ

SupabaseとNeon、どちらか一方が「上位互換」というわけではなく、そもそも解決しようとしている課題が違います。

• ログイン機能・ファイルストレージ・リアルタイム更新まで含めて「バックエンドを丸ごと」欲しいなら → Supabase
• ビルド時だけ触るシンプルなデータソースとして、複数プロジェクトを軽く運用したいなら → Neon

AstroやHugoで静的サイトをNetlifyにデプロイする、というこのサイトのような使い方に限って言えば、Neonのコンピュート課金とアカウント単位のプラン設計はかなり相性が良いです。とはいえ、会員機能やアップロード機能が絡んでくる案件では、これまで通りSupabaseの総合力が活きてきます。

「とりあえずどちらか」で決めるのではなく、そのプロジェクトがDBに何を求めているかで選ぶのが、結局いちばん失敗しない選び方だと思います。