#sqlite

この記事を読んでまず思ったのは、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 を作るのに、最初から大げさ