Relyt One のご紹介：コードのようにブランチできるサーバーレス Postgres

Relyt One は、開発者と AI エージェントのためのサーバーレス Postgres です。標準の PostgreSQL 17 に加えて、プルリクエストやプレビュー、エージェントの実行ごとに用意できるデータベースブランチ、誰も使っていないときは一時停止するコンピュート、そして多くのアプリが後から付け足すことになる機能（コネクションプーリング、ベクトル検索、Open API、マネージド認証）がそろっています。無料で始められ、クレジットカードは不要です。GitHub または Google でサインインすれば、数分後にはデータベースが手に入ります。

この記事では、Relyt One とは何か、なぜこのような設計になっているのか、そして実際に使うとどうなるのかを、最初の接続文字列から本番データを入れた使い捨てのブランチまで順を追って説明します。

Postgres は新しいアプリケーションのデフォルトのデータベースであり、それには十分な理由があります。一方で、その運用方法はあまり変わっていません。マネージドの Postgres インスタンスは、突き詰めればいまだに 1 台のマシンです。決まった量の CPU とメモリにディスクがつながっていて、誰がアクセスしていようといまいと動き続けています。

このモデルには、どのチームでも遅かれ早かれ表面化する 3 つのコストがあります。

環境が高くつくので、数が足りない。 本番そっくりのステージング用データベース、プルリクエストごとのデータベース、マイグレーションが安全に失敗できるサンドボックス。誰もが欲しがるものです。しかしマシン型の Postgres では、そのひとつひとつが、プロビジョニングするインスタンスであり、リストアするダンプであり、支払う請求書です。その結果、チームは 1 つのステージング用データベースを共有し、わずかなシードデータでマイグレーションをテストし、遅い ALTER TABLE に本番で初めて気づくことになります。

アイドル状態のデータベースにも、忙しいデータベースと同じコストがかかる。 サイドプロジェクト、社内ツール、プレビュー環境、デモアプリは、その生涯のほとんどを何もせずに過ごします。常時稼働のマシンは、その「何もしていない時間」のすべてに課金します。

エージェントは、どちらの問題も悪化させる。 タスクごとにデータベースを作り、スキーマ変更を試し、テストを実行して、結果を捨てられるコーディングエージェントは、開発用データベースを共有しなければならないエージェントよりはるかに役に立ちます。ただしそれが成り立つのは、データベースが git のブランチと同じくらい安く、速く作れる場合だけです。

Relyt One は、これら 3 つの問題をすべてなくすために、異なるアーキテクチャから出発しています。

中心にある考え方は、コンピュートとストレージの分離です。

ストレージは、データの履歴を保持する共有の層です。コンピュートは、1 つのブランチに対するクエリを処理し、ストレージからページを読み込む通常の Postgres 17 プロセスです。データがコンピュートのディスク上にないため、これまで高くついていた 3 つのことが安価になります。

ブランチとは、ある時点の親から始まる新しい履歴のラインです。ブランチを作成してもデータはコピーされません。新しいブランチは、どちらかが変更するまで親とすべてのページを共有し、変更されたページだけが新たに容量を使います。そのため、親のデータが 1 MB でも 100 GB でもブランチの作成コストは変わらず、コンソールでは各ブランチについて完全なコピーではなく親からのストレージ差分を表示できます。新しいブランチのコンピュートのプロビジョニングには少し時間がかかりますが、データは作成した瞬間からそろっています。

ブランチはツリーを構成します。main からブランチを作り、そのブランチからさらにブランチを作れます。ブランチを削除しても、親や兄弟のブランチには一切影響しません。ただし、子ブランチが残っているブランチは、子がすべてなくなるまで削除できません。プライマリブランチは削除できないので、main は常に存在します。

過去からブランチを作ることもできます。プロジェクトで履歴を保持している場合（プロジェクトの履歴保持設定で、最大で直近 3 時間まで）、新しいブランチは「現在」ではなく、その期間内の任意の時点の親のデータから始められます。これは、マイグレーションに失敗した朝に役立ちます。デプロイの 10 分前からブランチを作り、行がどうなっていたかを確認し、必要なものをコピーして戻せばよいのです。

各ブランチは、それぞれ専用のコンピュートで処理されます。コンピュートのサイズはコンピュートユニット（1 CU = 1 vCPU + 4 GB RAM）で指定します。プレビューブランチで重いテストを走らせても本番と CPU を奪い合うことはなく、エージェントの実験がユーザーの読んでいるテーブルをロックすることもありません。

コンピュートにやることがない状態がしばらく（デフォルトでは約 10 分）続くと、一時停止します。ステータスが ACTIVE から SUSPENDED に変わり、CPU を使わなくなります。データはそのままです。もともとコンピュート上にはないからです。次の接続があると再開します。1 日に数分しか忙しくならない大多数のデータベースにとって、これはマシンに対して支払うのか、仕事に対して支払うのかの違いになります。

• PostgreSQL 17 そのもの。似たものではありません。 お使いのドライバー、ORM、psql、pgAdmin、DBeaver がそのまま動きます。pg_trgm、citext、pgcrypto などの拡張機能も CREATE EXTENSION で利用できます。
• ブランチ：現在のデータ、または直近数時間内の任意の時点から作成でき、それぞれ専用のコンピュートを持ちます。コンソールからも API からも作成できます。
• コネクションプーリング：PgBouncer によるトランザクションレベルのプーリングで、最大 10,000 の同時接続に対応します。サーバーレス関数など短命な接続には、プーリング用の接続文字列を使ってください。
• ベクトル検索を標準搭載。 vectors 拡張機能（pgvecto.rs。pgvector ではありません）がプリロードされ、デフォルトでデータベースに作成済みなので、埋め込みベクトルを、それが表す行のすぐ隣に置けます。
• オブザーバビリティ：すべてのコンピュートについて、CPU、メモリ、接続数、データベースサイズのグラフ、実行中のアクティブなクエリ、呼び出し回数と所要時間を含むクエリ履歴を確認できます。
• Open API：組織、プロジェクト、ブランチ、コンピュートを API キーで操作できます。
• マネージド認証（プレビュー）。 アプリのユーザー向けのサインイン機能をブランチに紐づけて提供し、ユーザーはそのブランチ自身のデータベースに保存されます。詳しくは「Relyt One のマネージド認証、プレビュー版を公開」をご覧ください。

プロジェクトを作成し、接続し、ブランチを作り、そのブランチでスキーマを変更して、ブランチを捨てる。ここではその一連の流れをすべてたどります。

GitHub または Google でサインインします。初回サインイン時に無料の組織が自動で作成されます。

プロジェクトを作成します。名前を付け、リージョンを選び、PostgreSQL のパスワードを設定してください。プロジェクトは、プライマリブランチ main、プライマリコンピュート、データベース relytdb とそのオーナーロール relytdb_owner を持った状態で始まります。コンピュートのプロビジョニングには数分かかることがあります。準備ができたら、ブランチのページで知らせてくれます。

ブランチを開いて Connect（接続）を選びます。コンピュート、データベース、ロールを選び、接続文字列をコピーしてください。このダイアログには、Prisma と Java 向けのすぐに使えるスニペット、GUI クライアント向けのホストとポートの情報、プーリング用の接続文字列も用意されています。

export DATABASE_URL="postgresql://<ロール>:<パスワード>@<ホスト>/<データベース>?sslmode=require"
psql "$DATABASE_URL" -c "select version();"

ブランチの対象にするため、テーブルと行をいくつか作っておきます。

CREATE TABLE customers (
  id         bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  email      text NOT NULL UNIQUE,
  created_at timestamptz NOT NULL DEFAULT now()
);

INSERT INTO customers (email)
SELECT 'user' || g || '@example.com' FROM generate_series(1, 100000) AS g;

Branches（ブランチ）ページで New Branch（新しいブランチ）を選び、親として main を選択して、Current data（現在のデータ）のままにします。名前は add-plan-column とします。

ブランチには最初から 100,000 行すべてがそろっていて、専用のコンピュートと専用の接続文字列も持っています。コンピュートの準備完了が表示されたら接続してください。何もコピーされていません。親からのストレージ差分はゼロから始まります。

同じことを Open API で行うと次のようになります。CI ジョブやエージェントが使うのはこちらです（$PROJECT_ID はプロジェクトの obj-… ID、parentBranchSlug は親ブランチの br-… スラッグです）。

curl https://relyt.one/api/v1/projects/$PROJECT_ID/branches \
  -H "x-api-key: $RELYT_API_KEY" \
  -H "content-type: application/json" \
  -d '{"name": "add-plan-column", "parentBranchSlug": "br-..."}'

"pointInTime": "2026-10-30T08:50:00Z" を追加すると、その時点の親の状態からブランチを作成できます。指定する時刻は、プロジェクトの履歴保持期間内でなければなりません。

ブランチに接続して、自信のないマイグレーションを実行します。

ALTER TABLE customers ADD COLUMN plan text NOT NULL DEFAULT 'free';
CREATE INDEX customers_plan_idx ON customers (plan);

実データでどのくらい時間がかかるか、その後のクエリプランがどうなるか、アプリケーションが引き続き動くかが、main に一切触れることなくわかります。Monitoring（モニタリング）を開いてブランチのコンピュートを選ぶと、CPU のスパイクが見られ、Query History（クエリ履歴）では実行されたステートメントを確認できます。

結果に満足したら、いつものデプロイ手順で同じマイグレーションを main に適用します。満足できなければ、ブランチを削除するだけです。どちらにしても、この実験のコストは数秒分のコンピュートと、変更されたページだけです。

プロジェクトやブランチの作成と削除は API 呼び出しで実行できます。そのため Relyt One は、タスクごとに本物のデータベースを必要とするコーディングエージェントにぴったりです。

• Open API で、プロジェクトとブランチの作成・削除（各ブランチには専用のコンピュートが付きます）、コンピュートのステータスとメトリクスの取得、API キーの管理ができます。すべてのエンドポイントは API リファレンスに載っています。
• オープンソースの エージェントスキルパック は、Claude Code などのエージェントにプロビジョニング、ブランチ作成、接続の方法を教えるので、エージェントが当て推量をする必要はありません。
• タスクごとにブランチを。 エージェントに専用のブランチを与え、そこでマイグレーションとテストを実行させ、main に何かが届く前に差分をレビューしましょう。

すべてのアカウントは Free プランから始まります。

クレジットカードは不要で、試用期間の期限もありません。

データベースは Postgres であり、その周辺ツールもオープンです。マネージド認証のトークンを検証する @relyt/auth、サンプルアプリ、そしてエージェントスキルは、いずれも GitHub 上で MIT ライセンスで公開されています。

サインインしてプロジェクトを作成し、ブランチを作ってみてください。わかりにくい点や不具合があれば、ぜひお知らせください。コンソールのフィードバックボタンからお寄せいただけます。

無料でプロジェクトを作成