3つはそもそもカテゴリが違うため、単純な優劣比較ではなく「何をしてくれるサービスか」を先に整理する。
| サービス | 正体 | 一言で言うと |
|---|---|---|
| Amplify | AWSのフルスタックサービス | AWS版Firebase |
| Supabase | オープンソースのBaaS | PostgreSQL中心のバックエンド一式 |
| AWS RDS | AWSのマネージドRDB | DBエンジン単体 |
現在の構成: Next.js + Hono + Supabase
┌──────────────────────┐
│ Supabaseがやってること │
├──────────────────────┤
│ ・PostgreSQL (DB) │
│ ・認証 (Auth) │
│ ・Storage │
│ ・Realtime │
└──────────────────────┘
RDSに置き換えた場合:
→ PostgreSQLのみ
→ 認証はSupabase Auth相当を自前で実装が必要
→ StorageはS3を別途用意が必要
💡 ポイント: RDSは「DBだけ」、Supabaseは「DBを中心にしたバックエンド一式」。この違いが選定の核心。
| 機能 | Amplify | Supabase | AWS RDS |
|---|---|---|---|
| DB (PostgreSQL等) | ◎ | ◎ | ◎ |
| 認証 (Auth) | ◎ Cognito | ◎ 独自Auth | ✗ 自前実装 |
| API自動生成 | ◎ GraphQL | ◎ REST/GraphQL | ✗ 自前実装 |
| リアルタイム | ◎ | ◎ WebSocket | ✗ 自前実装 |
| Storage | ◎ S3連携 | ◎ 独自Storage | ✗ S3別途 |
| カスタムAPI (Honoなど) | △ 制約あり | ◎ 自由に構築 | ◎ 自由に構築 |
| AWS統合 | ◎ ネイティブ | △ 別途設定 | ◎ ネイティブ |
【Supabase + Hono】← 現在の構成
SupabaseはDBと認証を担当
HonoはカスタムAPIを自由に構築
→ 相性◎ 役割分担が明確
【Amplify + Hono】
AmplifyはGraphQL APIを自動生成するが
Honoと併用すると役割が被りやすい
→ 設計が複雑になりがち
【RDS + Hono】
RDSはDBのみ提供
認証・APIはHono側で全部実装が必要
→ 自由度最高だが実装コスト大
💡 ポイント: AmplifyはGraphQLを中心とした設計思想のため、Honoのような独自APIサーバーと併用すると役割が被りやすい。
| サービス | 得意 | 不得意 |
|---|---|---|
| Amplify | AWS統合・GraphQL中心設計・AWSに慣れたチーム | カスタムAPI構築・AWS以外との連携・学習コスト |
| Supabase | 個人・小規模開発・素早いプロトタイプ・カスタムAPI併用 | AWS統合・大規模トラフィック・複雑なDB運用 |
| AWS RDS | 大規模・高負荷・細かいDB設定・既存AWSインフラ統合 | 認証・API自前実装・初期構築コスト・個人開発には過剰 |
【小規模・個人開発】
Supabase
└── 認証・DB・Storageがすぐ使える
└── 無料枠で十分動く
└── Vercel + Hono との相性◎
【中規模・スタートアップ】
Supabase or Amplify
└── Supabase: カスタムAPI重視なら
└── Amplify: AWS統合・GraphQL重視なら
【大規模・エンタープライズ】
AWS RDS
└── 細かいパフォーマンスチューニングが必要
└── 既存のAWSインフラに統合したい
└── セキュリティ要件が厳しい
💡 ポイント: 個人開発でHonoを使うならSupabaseが三冠(相性・コスト・機能セット)で最適。
DBサービスを選びたい
│
▼
AWS縛りがあるか?
│
┌─┴─┐
No Yes
│ │
▼ ▼
Supabase GraphQL中心の設計か?
一択 ✅ │
┌─┴─┐
Yes No
│ │
▼ ▼
Amplify 大規模・高負荷か?
✅ │
┌─┴─┐
Yes No
│ │
▼ ▼
AWS RDS Supabase
✅ ✅
💡 ポイント: 「大規模・チューニング重視・認証は自前」という条件ならAmplifyではなくRDS。AmplifyはGraphQL・認証セットで使いたいケース向け。
| ミス | 改善策 |
|---|---|
| SupabaseをRDSの代替として選ぶ | SupabaseはBaaS(DB以外も提供)。DBだけ欲しいならRDSの方が適切な場合もある |
| AmplifyとHonoを併用してAPIが被る | HonoをメインにするならSupabaseの方が役割分担が明確 |
| 個人開発でRDSを選んで構築コストが増大 | 個人・小規模はSupabaseで十分。RDSは大規模向け |
| Supabaseのservice_role_keyをNEXT_PUBLIC_に付ける | service_role_keyは絶対にNEXT_PUBLIC_禁止。RLSをバイパスしてしまう |
- 現在の構成(Supabase + Hono + Vercel)は個人開発フェーズのベストプラクティス
- AmplifyはGraphQL中心なので、REST API / Hono を使う場合は採用理由が薄くなる
- 将来スケールしてAWSに移行する場合は RDS + Cognito + Hono の構成が有力候補
- Supabaseのservice_role_key管理には引き続き注意