Mythexのアプリに、それぞれ専用のデータベースが付く理由

Mythexで作ったアプリが、サインアップ、予約、注文などのデータを保存する必要がある場合、Mythexはそのプロジェクトに専用のPostgresデータベースを与えます。共有データベースの中のテーブルでも、他の人のスキーマの隣に置かれたスキーマでもありません。要求に応じて作られる、独立したデータベースです。誰も使っていないときはスリープします。なぜそのように作ったのか、そしてそのコストは何かを説明します。

得られるもの

「見込み客のメールアドレスを保存して」「予約を保存して」と頼むか、/databaseコマンドを使うと、Mythexは次のことを行います。

• プロジェクト専用のPostgresデータベースを作成します（現在はPostgres 17です）。
• 接続情報を、ワークスペースと公開済みアプリに環境変数として注入します。そのためコードには一切現れません。
• エージェントがテーブルを作成し、データを読み書きできるようにします。

ライブプレビューと公開済みアプリは、同じデータベースを使います。データベースは、5分のアイドル後にスリープし、次のクエリで目覚めます。新しいデータベースは小さく始まり、負荷に応じて拡張できます。ただし上限があるため、暴走したクエリが際限なく大きくなることはありません。詳しくはデータベースのドキュメントをご覧ください。

なぜ1つの大きな共有データベースではないのか？

各行にどのアプリに属するかを示す列を持たせた共有データベースは、運用が安く、単純です。しかし、私たちは次の4つの理由から、そうしないことにしました。

1. 信頼しなくてもよい分離

AIが書いたコードは間違えます。共有データベースでは、あるアプリのクエリにWHERE app_id = …が1つ抜けただけで、別の顧客のデータを読み取ったり、上書きしたりしかねません。アプリごとに独立したデータベースがあれば、他の顧客のデータに手が届くことはありません。バグは、そのアプリの中にとどまります。

2. 独自の層ではなく、本物のPostgres

アプリは、通常の接続文字列で標準のPostgresと通信します。Postgresで動くライブラリ、ORM、ツールはすべて、ここでも動きます。プロジェクトをエクスポートして別の場所で動かす場合も、Mythex専用のAPIではなく、どのホスティング事業者でも提供しているPostgresのデータベースを想定して動きます。

3. 各アプリを必要な形にできる

あるアプリは、時間枠に一意制約を持つbookingsテーブルを必要とし、別のアプリは商品の全文検索を必要とします。独立したデータベースがあれば、各アプリのスキーマとマイグレーションは、そのアプリ自身の問題になります。誰にも合う最大公約数的な設計に、無理に合わせる必要はありません。

4. コストは使用量に従う

各データベースは個別にスリープするため、誰も使っていないアプリにはほとんどコストがかからず、忙しいアプリのコストは独立した項目として見えます。公開済みのデータベースの使用量は、データベースが実際に計測した値をもとに請求されます。その請求の仕組みをご覧ください。

トレードオフ

この設計は無料ではありません。

• コールドスタート。 長く静かな時間の後、スリープしているデータベースは最初のクエリで目覚めるのに少し時間がかかります。ほとんどのアプリでは、ほぼ気になりません。しかし、いつでも即座に応答しなければならないアプリでは、考慮が必要です。
• 起きたままのコスト。 データベースは、何かがクエリを送っている間は起きたままです。数秒ごとにデータベースをポーリングするアプリは、一日中データベースを起こし続け、必要なときだけクエリするアプリより高くつきます。使用量が想定より多く見える場合、たいていはこれが原因です。その場合は、ポーリングをやめて、必要になったときにデータを読み込むようAIに依頼してください。
• 私たち側の仕組みが増える。 何千ものデータベースを作成、追跡、クリーンアップするのは、1つだけの場合より手間がかかります。それを背負うのは私たちの仕事であり、あなたの仕事ではありません。

データベースが初めての方へ

データベースとは、アプリが覚えておくべきものを保存する場所です。この考え方が新しい場合は、データベースとは何かとPostgresとは何かから始めてください。データを保存するものを作る準備ができたら、AIでアプリを作る方法で、それを追加する手順を説明しています。