#sqlite

SQLite に別の仕組みを重ねて、1台が落ちてもデータを失わないようにする。そんな発想から始まった rqlite が、12年たって「distributed SQLite」という一つの分野になった、と作者の Philip O’Toole は振り返っています。この記事が面白いのは、単なる自作ソフトの回顧ではなく、後から次々に似た製品が現れた流れを、最初から見ていた当事者が並べ直している点です。流行の起点を2021年ごろに置きがちな語り方に、2014年からの記録で待ったをかけています。 O’Toole が rqlite を最初に公開したのは2014年9月だった。考え方は単純で、SQLite の前に Raft のログを置き、書き込みを必ずクラスタへ複製する。そうすれば、1台のノードが壊れてもデータは消えない。ソースコードはその週末に GitHub に置いたという。彼はこれが、SQLite と Raft を組み合わせた最初のオープンソース実装だったと見ている。 rqlite は、彼自身が働いていたクラスタ型システムで「小さな関係データをどのノードに持たせるべきか」という実務上の悩みから生まれた

SupabaseがTursoを買収すると発表した。単なる企業再編に見えるかもしれないが、背景にあるのは「AIエージェントが大量のデータベースを、ものすごい勢いで作る時代」にどう備えるかという話だ。この記事は、そのインフラの変化を先回りして進めようとする動きとして読むと分かりやすい。既存ユーザーへの影響は小さいとされている一方で、SupabaseとTursoの組み合わせは、SQLiteからPostgresまでをまたぐ新しい道筋を作ろうとしている。 Supabaseは、Tursoを買収して自社に迎え入れると発表した。発表したのは2026年10月2日で、SupabaseのCEO兼共同創業者であるPaul Copplestoneが説明している。彼によれば、AIによって開発者は膨大な量のソフトウェアを作れるようになり、その結果としてエージェントがプロトタイプ、試作、ダッシュボード、アプリのために、何百万ものデータベースを立ち上げる状況がすでに起きているという。これまでのデータベース基盤では、その規模と使われ方に十分合っていないので、インフラを進化させる必要がある、というのが今回の出発点だ。 Su

この記事を読んでまず思ったのは、AI のメモリ機能って、便利そうに見えるけれど、雑にやるとすぐ壊れそうだということだった。 「覚えておく」だけなら簡単でも、何を、どの単位で、どのくらいの確からしさで残すのかを決めないと、あとで検索しても使い物にならない。そこに OKF みたいな形式を噛ませて、さらに SQLite FTS5 で引けるようにしているのは、かなり筋がいいと思う。単なる“気分のメモ”ではなく、検索できる記録に落としているのがいい。 ただ、読んでいて少し引っかかったのは、ここまで整えると今度は「AI の記憶」というより「人間が扱える知識ベース」にかなり寄っていくことだ。 それは悪いことではない。むしろ、AI の曖昧な内部状態に頼るより、ファイルとして見えて、消せて、タグで絞れて、履歴も残る方がずっと安心感がある。けれど同時に、これって本当に“記憶”なのか、という感覚は残る。実態は、上手に整理された外部メモ帳に近いのではないかと思う。 その「外部メモ帳」にも、ちゃんと思想があるのが面白い。memory/ に Markdown を吐き出して、人間がブラウザで読めるようにしつつ、裏で

Codex CLI がローカルの SQLite ログに、想像以上の量を書き込んでいた 1年換算で約640TBもの書き込みになりうる、という指摘が出た これは SSD の寿命、つまり「書ける回数の限界」をじわじわ削る 原因は、TRACE などの細かすぎるログを広く残しすぎていたこと その後、ログの量を減らす修正がマージされ、問題はかなり改善された この Issue を読んでまず思ったのは、「ログって便利だけど、やりすぎると普通に凶器になるんだな」ということです。ふだんログは、何か問題が起きたときに頼る“記録係”みたいな存在です。でも Codex のこの件では、その記録係がほぼ24時間、延々とメモを取り続けていたわけです。しかも保存先は SQLite データベース。これは軽く見えるけれど、書き込みが多すぎると話が変わります。 この Issue のタイトルはかなり直接的で、要するに「Codex の SQLite feedback logs が、年間約640TBもの書き込みを生み、SSD の耐久性を急速に消耗させる」という警告です。報告したユーザーは、実機で21日ほど動かしたところ、メインSS

この記事は、「durable execution（壊れにくい実行）」には、必ずしも巨大な基盤は要らないと主張しています。 DBOS が「Postgres があれば十分」と言った流れに対して、Obelisk は「もっと進めて、SQLite でも多くのケースで十分では？」と提案しています。 重要なのは 計算処理そのもの ではなく、workflow の状態を安全に残すこと だ、という考え方です。 SQLite は単体で transactional な永続性を持てるので、余計な DB サービスを増やさずに済みます。 Litestream を使えば、SQLite の変更を S3 互換の object storage に非同期でバックアップできます。 ただしこれは高可用性の共有DBの代わりではなく、多少の遅延や一部データ喪失の可能性を許容する設計です。 AI agents や実験的な workflow には、Postgres より SQLite のほうがシンプルで相性がいい場面が多い、というのがこの記事の見立てです。 「durable workflows を作るのに、最初から大げさ