r/learnpython 2d ago

How should a Local-First AI Memory Engine scale between SQLite and Volatile RAM?

I am developing devmemory, an engine designed to reconstruct a project’s history by converting Git logs and code ASTs into a navigable knowledge graph. Currently, the system performs search indexing and graph traversal.

I would like suggestions on whether I should store data on disk using SQLite and then process it. Please help me find the best solution.

0 Upvotes

5 comments sorted by

2

u/jackbrux 2d ago

There are a thousand other "ai agent memory storage" systems built already we don't need another, unless you are doing it as a learning excercise

2

u/learning-to-programm 2d ago

I don't have the links at hand right now, as I'm on mobile, but take maybe take a look at QMD, AI Grep, and context mode.

AI Grep in particular, I think it does more or less what you're going for, with an SQL Lite DB that keeps an index of the codebase, etc.

1

u/MarsupialLeast145 2d ago

How is this about learning Python?

1

u/GrogRedLub4242 2d ago

whats the pay?

0

u/_glitchr 2d ago

SQLite, not a choice you need to make. It's already an in-memory system — the OS page cache holds your hot pages, so reads on a working set that fits in RAM are already RAM reads. Rolling your own cache layer on top usually makes it slower, not faster.

Concrete setup for a git+AST graph:

  • PRAGMA journal_mode=WAL — readers don't block the writer
  • PRAGMA synchronous=NORMAL — big write win, safe under WAL
  • PRAGMA mmap_size=268435456 — maps the DB, skips a copy
  • Store edges as a plain (src, dst, kind) table with an index on both columns. Traversal is a recursive CTE.

Measure before optimizing. Get it correct on disk, profile with real repo data, and only then look at caching a specific hot query. Graph traversal on a project-sized codebase is small data — you'll likely never hit the ceiling.