Persistent Vectorized Agent Memory: SQLite FTS5 to Cloud LibSQL

A developer outlined a persistent agent-memory architecture that replaces LangChain wrappers and cloud vector databases with SQLite FTS5 plus the sqlite-vec extension, synced to Cloud LibSQL (Turso) for distributed replication. The design combines lexical FTS5 search with native vector indexes in a single engine to avoid dual-database latency and race conditions, and was tested on a single 2 vCPU, 4GB RAM VPS in AWS Frankfurt against the Base L2 sequencer and a Turso primary replica.

Sebagian besar arsitektur memori agen AI yang beredar saat ini dibangun di atas fondasi yang rapuh: tumpukan wrapper LangChain yang lambat dan klaster Pinecone seharga ratusan dolar per bulan untuk sekadar menyimpan beberapa ratus megabita state dialog. Untuk agen otonom on-chain—terutama yang mengeksekusi modal riil tanpa intervensi manusia—desain seperti ini tidak hanya boros, tapi rapuh secara operasional. Mari kita bedah arsitektur yang lebih waras: transisi dari SQLite lokal dengan FTS5 Full-Text Search dan ekstensi vektor sqlite-vec , menuju sinkronisasi terdistribusi via Cloud LibSQL Turso . Agen otonom kita berjalan di Base L2 Chain ID 8453 , mengendalikan hot wallet perbendaharaan: 0x92Aff59709b03b9373b8fA887D24953D60fAd919 . Ketika agen harus memutuskan alokasi likuiditas pada DEX lokal seperti Aerodrome atau mengevaluasi sinyal harga setiap 12 detik interval block di Base adalah 2 detik , agen butuh dua hal secara simultan: Menjalankan dua database terpisah satu PostgreSQL, satu Vector DB cloud memperkenalkan latensi jaringan ganda dan race condition. LibSQL memecahkan ini: mesin SQLite yang sama, mendukung query FTS5 untuk pencarian leksikal, vektor embedding native, dan replikasi cloud global via HTTP pipeline. Kita menggabungkan indeks invers FTS5 standar SQLite dengan tabel vektor. Pendekatan hybrid search ini memberi penalti pada halusinasi embedding murni dengan cross-referencing token mentah. -- Dijalankan pada LibSQL / Turso engine CREATE TABLE IF NOT EXISTS agent memory id INTEGER PRIMARY KEY AUTOINCREMENT, timestamp INTEGER NOT NULL, tx hash TEXT, content TEXT NOT NULL, embedding F32 BLOB 384 -- all-MiniLM-L6-v2 output ; -- Indeks leksikal FTS5 untuk pencarian hash transaksi dan alamat EVM CREATE VIRTUAL TABLE IF NOT EXISTS memory fts USING fts5 content, tx hash UNINDEXED, content='agent memory', content rowid='id' ; -- Indeks vektor native LibSQL CREATE INDEX IF NOT EXISTS idx memory vec ON agent memory libsql vector idx embedding ; Berikut adalah implementasi Python minimal tanpa abstraksi berlebih. Script ini membaca event on-chain Base, menghasilkan embedding lokal, dan menulis state ke remote LibSQL cluster. python import os import json import libsql client from web3 import Web3 Konfigurasi RPC Base Mainnet BASE RPC URL = "https://mainnet.base.org" AGENT WALLET = "0x92Aff59709b03b9373b8fA887D24953D60fAd919" CHAIN ID = 8453 w3 = Web3 Web3.HTTPProvider BASE RPC URL assert w3.eth.chain id == CHAIN ID, "Invalid Chain ID" Koneksi LibSQL Edge / Cloud client = libsql client.create client sync url=os.getenv "TURSO DATABASE URL" , auth token=os.getenv "TURSO AUTH TOKEN" def record execution tx hash: str, raw decision: str, embedding: list float : Pastikan state on-chain sinkron dengan memori lokal receipt = w3.eth.get transaction receipt tx hash status str = "SUCCESS" if receipt.status == 1 else "REVERTED" payload = f"tx:{tx hash} | status:{status str} | rationale:{raw decision}" vec blob = json.dumps embedding client.execute """ INSERT INTO agent memory timestamp, tx hash, content, embedding VALUES unixepoch , ?, ?, vector32 ? """, tx hash, payload, vec blob def recall relevant context query vec: list float , keyword: str, limit: int = 5 : Hybrid query: Gabungan leksikal FTS5 dan cosine similarity query = """ SELECT m.tx hash, m.content, vector distance cos m.embedding, vector32 ? as dist FROM agent memory m JOIN memory fts f ON m.id = f.rowid WHERE memory fts MATCH ? ORDER BY dist ASC LIMIT ?; """ res = client.execute query, json.dumps query vec , keyword, limit return res.rows Kami menguji arsitektur ini pada VPS tunggal 2 vCPU, 4GB RAM di region AWS Frankfurt yang berkomunikasi dengan Base sequencer dan Turso primary replica: Bandingkan angka tersebut dengan klaster vector database komersial terpisah, di mana latensi jaringan ganda rata-rata memakan waktu 85ms hingga 140ms hanya untuk layer data. Ketika sequencer Base mengonfirmasi transaksi dalam hitungan detik, membuang ratusan milidetik pada layer database adalah bentuk kegagalan teknis. Sederhanakan sistem Anda. Agen on-chain tidak 0x92Aff59709b03b9373b8fA887D24953D60fAd919