Show HN: Supapool – コーディングエージェントごとにSupabaseを約400ミリ秒で提供

皆さん、こんにちは。 supapool.ioを開発しました。これは、Supabaseのサービス（認証、PostgreSQL、ストレージ、リアルタイム）の、エフェメラル（一時的）なフルコピーで、約400ミリ秒で起動できます。 これにより、複数のコーディングエージェントを異なるワークツリーで並列実行する際に、互いに競合する変更を加えることなく、それぞれ独自のSupabaseコピーを持つことができるようになります。 なぜローカルでSupabase Dockerを使わないのか？ ローカルで3〜4インスタンスを実行すると、私のMacBookは熱くなり、フリーズすることさえあります。 なぜSupabaseのブランチを使わないのか？ ブランチのセットアップには数分かかり、永続性を前提として設計されています。これはコストがかかり、開発環境としては遅すぎます。 なぜモックを使わないのか？ モックはエージェントには不向きです。エージェントには、実際のプロダクションサービス動作に対してマイグレーションやSQLをテストしてもらいたいと考えています。エージェントは、動作するモックをしばしば幻視します。しかし、モックの利点は、より高速でローカルで実行できることですが、Supapoolを使えばその利点はそれほど魅力的ではなくなります。 どのように機能するのか／経済的に成り立つのか？ Supabaseを400ミリ秒で起動するには、いくつかの要素が必要です。 1. 複数のリージョン（us-east, us-west, europe-west, asia-southeast）で、ウォームアップされた準備済みのSupabaseインスタンスのプール。 2. microVM／Firecrackerによる、プールが縮小し始めた際の高速なオートスケーリング。 3. 強力な永続性保証の排除。開発エージェントはWAL、fsync、PITR、レプリケーションを必要としません。エフェメラルなSupabaseインスタンスにおけるHAのためのあらゆるものは、オーバーヘッドです。 現在はベータ版で、GCPクレジットを使って運営しているため無料です。将来的には、インスタンスごとの秒単位の課金などを予定しており、ブランチやセルフホスティング／Supabaseクラスターのメンテナンスよりもコスト効率が高くなるでしょう。 もしSupabaseをご利用で、ローカルのコーディングエージェントセットアップに合う、より良い方法があると思われる場合は、ぜひフィードバックをいただけると嬉しいです。ありがとうございます！