韓国語でのコメントが来るとは思っていませんでした！ (少し辛辣に書きすぎてしまいました...)

まずは画期的なアイデアだと思いました。実際、サーバーレスDBの一番の問題点は、表面上は見えない場所で実際のサーバーが動いていることでした。だからトラフィックが集中すると、そのサーバーが割り当てられるまでフリーズしてしまう状況が発生します（大体5分程度）。なので、現存するクラウド（AWSなど）のサーバーレスDBは本番レベルで使うのが難しいんですよね。

やってみようかとも思いましたが、心配だったのは、mysqlやpostgresqlなどで作られたインデックス作成、ソートといったバイナリロジックを実装しなければならなくなる場合、信頼できるオープンソースDBプロジェクトをLambda上で再構築するのがどれほど難しいことか、ということです。

直接作っている製品なので、今後の大きな発展を期待しています〜！

ありがとうございます、きっととても役に立つと思います ✌️

最初は n8n で構成していましたが、AWS Lambda + @ に切り替えました 🙇‍♂️

• AWS Lambda: 購読申請/解除 API（無料枠）
• DynamoDB: 購読者管理（無料枠）
• 別途サーバー: メール送信（無料）
• AI: JinaAI, OpenAI API（有料）

こんな感じで運用しています（笑）
一度作ってみるのをおすすめします。楽しいですよ 👍

貴重なご意見ありがとうございます。ご指摘の「レイテンシを下げるためにはstateが必要だ」という点は、私たちのアーキテクチャの重要なトレードオフを正確に捉えています。

まず、クエリのレイテンシについて述べると、私たちのベンチマークではp99（99th percentile）は約130〜210ms程度です。おそらく「100倍差がある」とのご指摘は、本文で言及している「コールドスタート時には数秒かかる場合がある」という最悪ケースを見てのことかと思われます。ご指摘の通り、この点は明らかに当社アーキテクチャの欠点であり、記事で述べたように、プロダクション環境では0.01%未満（P99.99）で発生します。そのほか、ほとんどのクエリは各Lambdaのローカルメモリとディスクをキャッシュとして活用するよう設計され、安定したパフォーマンスを実現します。

したがって、すべてのクエリが10ms以下で保証される超低遅延の金融取引システムなどには、このアーキテクチャが適していない場合があります。
ただし、大半のAIベースの検索・レコメンデーションアプリケーションでは、P99基準で100〜200ms程度のレイテンシは十分に優れたパフォーマンスであり、インフラコストと運用負担を90%以上削減できる利点の方がはるかに大きいと考えます。

改めて、深いご意見をいただきありがとうございました。

65GBなので……残念ですね（涙）

私もやってみようかと思ったものの、できなかったサービスですね.. 笑
もしかして n8n で構成しましたか??

「開発者は心配していない」で言われている開発者というのは、ある程度キャリアを積んだシニアのことなんでしょう。そうでなくても会社の立場からすると新卒や未経験者を採用する理由は減っているのに、そこへAIまで登場し、しかもAIの活用はシニアのほうがうまいのは目に見えていますからね……

問題は、ジュニア層は波に乗れず、たとえ波に乗って深く進んでも、その波にのみ込まれかねないということです。

でも、AEOやGEOも結局はSEOと重なる部分があるので……。

毎朝の楽しみができましたね。購読しました。

波に逆らう人や逃げる人はのみ込まれ、波に乗る人はその波を楽しむことになるだろう..

LLMで画像化されたもののようですが、見やすくていいですね。

自分も似たように試してみようと思います。

ありがとうございます 👏

32GBあれば十分だと思っていたのに…。

• Go 1.25 encoding/json v1 と v2 の比較: https://gosuda.org/ko/blog/…
• Go ランタイムが奪っていく緑茶一杯の余裕、GreenTea GC: https://gosuda.org/ko/blog/…

ひとまず lm studio M4 Max 64GB では動きません（泣）

シンプル・イズ・ベスト！

購読を申し込みました。👍

発想自体は良いですが、クエリのレイテンシを下げるためには必然的にステートが必要になってきます。MySQL、PostgreSQL などと比べると、クエリレイテンシがほぼ100倍程度高く感じます。ほとんどファイルシステムに対して読み書きしているのと似ているようです。