Show HN: Rekal – Long-term memory for LLMs in a single SQLite file • Hacker News Board

Show HN: Rekal – Long-term memory for LLMs in a single SQLite file

#1

Post by jeeybee » Sun, Apr 12, 2026, 9:25 PM UTC

I got tired of repeating myself to my LLM every session. rekal is an MCP server that stores memories in SQLite and retrieves them with hybrid search (BM25 + vectors + recency decay). One file, local embeddings, no API keys.

Show HN: Rekal – Long-term memory for LLMs in a single SQLite file
github.com

Re: Show HN: Rekal – Long-term memory for LLMs in a single SQLite file

#2

Post by maxbeech » Sun, Apr 12, 2026, 9:32 PM UTC

[dead]

Re: Show HN: Rekal – Long-term memory for LLMs in a single SQLite file

#3

Post by axeldunkel » Sun, Apr 12, 2026, 11:33 PM UTC

Nice clean project - Python 3.14 as a requirement might be an issue for adoption...

Re: Show HN: Rekal – Long-term memory for LLMs in a single SQLite file

#4

Post by jeeybee » Mon, Apr 13, 2026, 6:16 AM UTC

axeldunkel wrote: post #3

Nice clean project - Python 3.14 as a requirement might be an issue for adoption...

Thanks! You're right, that's just a relic of my dev environment. Will broaden the version requirement.

Re: Show HN: Rekal – Long-term memory for LLMs in a single SQLite file

#5

Post by eitanlebras » Mon, Apr 13, 2026, 6:54 PM UTC

The hybrid search scoring is really well thought out. One question: are the 0.4/0.4/0.2 weights fixed or configurable? To me it feels like different use cases would want different balances (e.g. a coding assistant would want higher recency weights than a research tool would).

Re: Show HN: Rekal – Long-term memory for LLMs in a single SQLite file

#6

Post by SachitRafa » Mon, Apr 13, 2026, 7:17 PM UTC

All memories should not decay at the same rate. these weights should be configurable !

Re: Show HN: Rekal – Long-term memory for LLMs in a single SQLite file

#7

Post by jeeybee » Mon, Apr 13, 2026, 9:10 PM UTC

eitanlebras wrote: post #5

The hybrid search scoring is really well thought out. One question: are the 0.4/0.4/0.2 weights fixed or configurable? To me it feels like different use cases would want different balances (e.g. a coding assistant would want higher recency weights than a research tool would).

The 0.4/0.4/0.2 weights are just based of hand wavy trail an error, will look into other options. I could make them configurable?

Re: Show HN: Rekal – Long-term memory for LLMs in a single SQLite file

#8

Post by jeeybee » Mon, Apr 13, 2026, 9:10 PM UTC

SachitRafa wrote: post #6

All memories should not decay at the same rate. these weights should be configurable !

Thanks, i will look into making them configurable.

Re: Show HN: Rekal – Long-term memory for LLMs in a single SQLite file

#9

Post by alsetmusic » Mon, Apr 13, 2026, 9:21 PM UTC

I’m going to try this out. Curious how effective it’s been for your own use, OP? Anything particularly interesting or where it still falls over and requires tuning that you’ve observed? I find these types of projects interesting in sort of an anthropological sort of way. So far, I’ve yet to try anything that hasn’t still required a great deal of intervention to keep agents using guardrails without scolding them to do so. I guess this might force them more reliably, but I’ll need to try it and find out.

Re: Show HN: Rekal – Long-term memory for LLMs in a single SQLite file

#10

Post by eitanlebras » Mon, Apr 13, 2026, 9:48 PM UTC

jeeybee wrote: post #7

eitanlebras wrote: post #5

The hybrid search scoring is really well thought out. One question: are the 0.4/0.4/0.2 weights fixed or configurable? To me it feels like different use cases would want different balances (e.g. a coding assistant would want higher recency weights than a research tool would).

The 0.4/0.4/0.2 weights are just based of hand wavy trail an error, will look into other options. I could make them configurable?

I think that'd be cool, maybe just a simple config option in pyproject.toml or a .rekal/config.yml would cover most use cases: they could default to 0.4/0.4/0.2 but could be overriden.