それは納得できるね。LiteFSはFUSEを使ってたから、カスタムファイルシステムをどうやって実行してマウントするかを考えなきゃいけなかった。Litestreamは、SQLiteデータベースファイル（とそのWALファイル）を指すだけの単一のコンパイル済みGoバイナリなんだ。

SQLiteだけで十分なら、なんでPostgresを使うの？Postgresは、ユーザーが少なくて高度なデータベース機能がいらないシンプルなアプリにはオーバースペックすぎるよ。

人々が楽しんでいる大きな利点の一つは、アプリケーションサーバーとDBの間のネットワーク遅延がなくなることだよ。SQLiteだと、DBがすぐそばにあって、NVMEで直接接続されてることが多い。これで全てのアクセス遅延が改善されて、他のDBではアンチパターンとされるN+1クエリのようなパターンも可能になるんだ。

よくわからないけど、やったことないから、考えとしては多くの小さな顧客特有のデータベースを持って、それを顧客の近くでSQLiteで動かすってことかな。でも、信頼性のあるSQLiteのユースケースについてもっと詳しい人から話を聞きたいな。

いい質問だね。最近のSQLiteの盛り上がりでは十分に答えられてないと思う。俺の意見では、PostgresやMySQLを簡単に使えるなら、それを使った方がいいよ。DBの使い方には細かいクセがあって、最初は気づかないことも多いから、何回か痛い目にあったことがある。サポートされてない機能や、意味が違ったりすることもあるし。俺的には、どのプロジェクトにも「実験的なもの」に使える予算があって、それを超えると手に負えなくなることが多い。ほとんどのプロジェクトでは、新しいデータベースにお金を使うほどのメリットはないと思う。

一般的な答え（特にFly.ioから）は「エッジコンピューティング/クエリ」だね。MySQLやPostgresにクエリを送ってデータを返してもらうのにはネットワークの遅延があるけど、Litestreamを使えば、全SQLite DBの読み取りレプリカをエッジに置ける。クエリはローカルの読み取りレプリカに対してだけ速くて効率的になる。時間が経つにつれてその読み取りレプリカを更新するのにはネットワークの遅延がまだあるけど、全体の書き込み数に基づいて分散されるから、クエリの数には依存しないし、「最終的に整合性がある」ワークフローではもっと耐障害性が高い（ネットワークが再接続されて、欠けていた書き込みを再生するのを待っている間に、エッジの読み取りレプリカからクエリに答えられる）。SQLiteがバックになっているから、MySQLやPostgresのような大きな（または「ちゃんとした」）データベースから期待されるSQLのフルリレーショナルDBクエリの力もまだ持ってる。

かなり速くて、運用のオーバーヘッドも少ない。それだけ。だけど、ほとんどのアプリはPostgresみたいなクラシックなNティアデータベースアーキテクチャを使うべきだと思う。俺たちもそうしてるし（Litestreamはトークンシステムみたいな一部のものをバックアップしてるけど）。

今はこの考えに近いかな。SQLiteの垂直スケーリングが必要なケースでは、顧客が単にブロックストレージデバイスを設定して定期的にスナップショットを取ってた。Litestreamはほぼ同じアイデアで、クラウドにいることでブロックデバイスのスナップショットを暗黙的に得られる。余計な機械を気にする必要もないし、パスやファイルを忘れることもない。S3へのストリーミングレプリケーションは、リカバリーの観点からはあまり価値がないと思う。他の解決策は数秒以内にホットで準備完了のレプリカをサポートしてるし。

どんなデータベースを使うにしても、何らかのバックアップソリューションが必要だよ。Litestreamはストリーミングバックアップソリューションで、耐久性のためのレプリケーションとしても機能する。MySQLやPostgresなんかは、設定のオーバーヘッドがかなり大きいけど、マネージドデータベースを使うなら別だけど、小規模なデータにはその価格に見合わないと思う。

自分でデータベースを運営して、インシデントやバックアップ、レプリカ、フェイルオーバーとかに悩まされるのを避けるために、安いS3みたいなストレージを使って、アプリケーションをステートレスに運営できるよ。もし自分のためにしっかり管理されたデータベースにアクセスできるなら、多くのユースケースでそっちを選ぶべきだと思う。

これは単一ユーザー向けのアプリのインフラだね。SQLiteはMSAccessみたいなファイルデータベースの代わりに最適だけど、サーバーが落ちたらデータベースも死んじゃうから、データが全部消えちゃう。だから、データベースをサービスとして提供することで、バックエンドを用意しなくても、クオリティ・オブ・ライフを向上させるってわけ。そうじゃないと、プロビジョニングやアップデートとか、面倒なサービスの維持に時間を取られちゃうし、本当に必要なのは自動でバックアップされるファイルか、ローカルファイルシステムの欠点を避けるためのウェブ上のどこかに置かれたファイルだけなんだよね。

俺は昔、アプリサーバーとデータベースが同じラックにあった製品で働いてたから、似たような低遅延だった。でも、その製品は成功したから、N+1が何千ものクエリを生み出して、1msが簡単に500ms以上になっちゃった。毎月New Relicを見て、遅いポイントを見つけてた。Railsアプリだったから、N+1に陥るのは簡単だったけど、修正も比較的簡単だった。

N+1って何？

まあ、それを考えると、そんなに大きなトレードオフじゃないよね。だって、君が言ってることは、そんなサービスを使うと自分のコードがどれだけクソか見せつけられるってことじゃん。それはサービスのせいじゃないし。:)

悪いクエリの書き方は、結局いつか痛い目にあうよ。これをこのアプローチの欠点とは呼ばないかな。

一台のボックスでかなりのところまで行けると思うよ。シングルインスタンスで20TB以上のRAMと何百ものコアを使えるから、これはオプションとしてあまり探求されていないかも。さらに、ユーザーやテナントで分けるセルベースのアーキテクチャと組み合わせると、サービス自体を分けるよりももっと面白くなると思う。

Litestreamは基本的にそれだね。ただ、OPの記事の下の方に「次に作る大きな機能は、リードレプリカ用のLitestream VFSです」って書いてある。https://litestream.io/guides/s3/ これってTursoにもだいたい当てはまると思うけど、TursoはバニラじゃなくてSQLite互換のデータベースになりつつあるね。https://docs.turso.tech/features/embedded-replicas/introduct... https://docs.turso.tech/cloud/durability

LiteFSはそれができるけど、カスタムFUSEファイルシステムを動かさないといけないから、Litestreamの方が人気があるんだよね。https://fly.io/docs/litefs/how-it-works/#capturing-sqlite-tr... 今、Litestreamはそれに取り組んでるところで、コードはもうここにあるよ。https://github.com/benbjohnson/litestream/blob/v0.5.0/vfs.go でも、まだ動作するドキュメント化された機能にはなってない。

つまり、OPの「次は何？」ってそのままのことだよね。https://fly.io/blog/litestream-v050-is-here/#whats-next 彼らはもうプロトタイプを持ってるし、結構荒削りだけど。俺はそれを自分のGo SQLiteドライバーに移植してるところで、すでにいくつかの問題にぶつかってる。でも、少なくとも動作する形に持っていくのは可能そうだ。https://github.com/benbjohnson/litestream/issues/772 https://github.com/ncruces/go-sqlite3/compare/main...litestr...

同じことが気になるけど、条件付き書き込みを使って新しいプライマリを自動的に選出できるのかも気になるな（Fly.ioが言ってるように、CASAAS: Compare-and-Swap as a Serviceってやつね）。

ありがとう、何が良かったの？

公開されているベンチマーク（と自分のアプリケーション）から見ると、modernc.org/sqliteには小さな（ほとんど気づかない）パフォーマンスのペナルティしかないし、CGOを排除できるメリットの方がはるかに大きいね。今後のプロジェクトでも迷わず使うよ。