マネージド PostgreSQL – パブリックベータ

Postgres を、余計なものは削ぎ落とす

プロジェクトごとに、独立したデータベースセルが 1 つ。専用の Postgres と本物の接続文字列が、npm install の終わる前に使えるようになります。

connect.sh

$ capydb create

postgres://user:pass@myapp.db.capydb.dev:5432/main

エージェントに任せることもできます

このプロジェクト用に CapyDB の Postgres データベースを用意してください。 https://capydb.dev/agents.md を取得し、あなたの環境に合った手順に従ってください。 私の出番は 1 回だけです。ブラウザのタブでアクセスを承認します。あとはすべてお任せします。

Claude Code、Cursor、Copilot などに対応。ブラウザーでの承認 1 回だけで、アカウント・データベース・環境変数まで整います。

グリッドの状態 · 全ノード正常

/a

独立したセル

誰かの Postgres の一区画ではありません。

/b

本物の Postgres

Postgres を話せるものは、そのまま動きます。

/c

使い捨てのプレビュー

マージしたら、そのまま破棄。

/d

時間をさかのぼる

直近 30 日の任意の 1 秒に戻せます。

01基本単位

1 プロジェクトに、1 セル

データベースはサービスの単位です。CapyDB のそれが「セル」で、専用のプロセス・ストレージ・認証情報・拡張機能・CPU/メモリ上限を持つ独立した Postgres です。セルの運用は CapyDB が担い、使うのはごく普通の Postgres の URL だけです。

01基本単位
awaiting signal

仕様一覧

一つの単位を、きちんと作る。

01

データベースセル

プロジェクトごとに独立した Postgres が動きます。専用のプロセス・ストレージ・認証情報・拡張・CPU/メモリ上限つき。数秒で使えます。

プロセス · ストレージ · 認証情報 · cpu/メモリ

02

使い捨てのプレビュー

プルリクエストごとに、本番を新しいセルへ複製します。ブランチとともに期限切れになり、TTL が後片付けをします。

即時クローン · 自動失効

03

SDK ではなく、接続文字列

標準の postgres:// URL を、直接接続でもプール経由でも。Postgres を話せるものはそのまま動きます。お使いの ORM も、CLI も、15 年前の GUI クライアントも。

sdk なし · 方言なし · 囲い込みなし

04

分離の内訳

プロセス、認証情報、ストレージ容量、ネットワーク、CPU、メモリ。すべてセル単位で分離されます。TLS は常時必須、認証情報のローテーションはコマンド 1 つです。

全経路 tls · 即時ローテーション

05

任意時点への復元

トランザクションログを継続的にアーカイブします。直近 30 日の任意の 1 秒を、新しいセルへ復元できます。テーブルを消してしまう日は、いつか必ず来ますから。

pitr · 30 日間

02プレビュー用データベース

PR ごとに 専用のセル

プレビュー用データベースはブランチとともに生まれ、ブランチとともに消えます。専用のセルで動き、専用の接続文字列を持ち、本番には一切触れません。

02プレビュー用データベース
awaiting signal

03ゼロスケール

使わなければ休む。つなげば起きる。

アイドル状態のセルは計算資源を手放し、ストレージはそのまま保持します。接続すれば戻ってきます。通常は 1 秒とかかりません。接続文字列は変わりません。

03ゼロスケール
awaiting signal

手間は、ゼロ

3 つのコマンドで、もう出荷できます

01

作る

1 プロジェクトに 1 セル。数秒です。

capydb create
02

つなぐ

いま使っている道具が、そのまま動きます。

DATABASE_URL=postgres://…
03

出す

PR ごとにプレビュー。マージしたら破棄。

git push && npm run deploy

04リージョン

ノードの上にセル。ノードが作る グリッド。

決めるのはリージョンだけです。セルは、私たちが自ら所有し現地で運用しているハードウェアに配置されます。グリッド上のどのノードも、同じ退屈な構成で動いています。

04リージョン
awaiting signal

05作らなかったもの

私たちが 作らなかったもの。

認証アドオンはありません。ストレージバケットもありません。関数の実行環境もありません。独自に書き直したストレージエンジンもありません。標準の Postgres を、極めて丁寧に運用する。開発の時間はすべてそこに使いました。

05作らなかったもの
awaiting signal

06「独立」の中身

独立しています。誇張なしで。

共有の Postgres サーバーではありません。プロジェクトごとに独立した Postgres が用意され、プロセス・認証情報・ストレージ容量・ネットワーク・CPU・メモリがそれぞれ分離されます。標準プランで共有されるものが一つだけあります。ストレージ I/O はベストエフォートです。

06「独立」の中身
awaiting signal

正直な相性チェック

道具は、選んでこそ

CapyDB が向いているのは

  • バックエンド基盤ではなく、マネージドな Postgres がほしい場合。
  • 独自 SDK より接続文字列のほうが好みの場合。
  • PR ごとにデータベースを複製している場合。
  • いまの開発ツールをそのまま使い続けたい場合。

別の選択肢が向いているのは

  • 認証・ストレージ・関数実行までまとめて必要な場合。
  • GraphQL / REST API の自動生成が必要な場合。
  • 特定ベンダーへの依存を許容できる場合。
  • SQL を書かずに済ませたい場合。

基盤一式がほしいなら、基盤を買ってください。Postgres を全力で使いたいなら、CapyDB を。

セルフサービスのプランは 1 か月無料

セルを、立ち上げる

無料で始める$ capydb create