Inspiration
I wanted to build something I'd actually use myself — a journal that doesn't just store what I write, but remembers it in a way that's actually useful. Most journaling apps are just a text box and a search bar that only matches exact words. I wanted to ask "what was I stressed about last week?" in plain English and have it find the right entry, even if I didn't use the word "stressed" in it.
What it does
Recall is a personal journaling agent with persistent, semantic memory. You write entries through a simple CLI. Later, you ask questions in natural language, and it retrieves the most relevant past entries based on meaning — not keyword matching — using CockroachDB's native vector search.
python app.py write "Studied for DBMS exam, felt stressed about normalization"
python app.py ask "what was I stressed about?"
How I built it
- CockroachDB is the entire memory layer. Every entry is stored in a
journal_entriestable alongside its embedding, in a nativeVECTORcolumn with avector_cosine_opsindex. Semantic search is just a SQL query:ORDER BY embedding <-> $query LIMIT 5. No separate vector database, no sync gap between the source data and the embeddings — everything lives in one transactional, always-on store. - I used the CockroachDB Cloud Managed MCP Server during development to inspect the cluster, debug the vector index, and iterate on schema directly from the terminal via Claude Code.
- The app itself is a small Python CLI (
write,ask,list,clear) built aroundpsycopg2for the CockroachDB connection.
Challenges I ran into
- AWS account verification: I wasn't able to get an AWS account
verified in time for this submission, so Bedrock (which I'd planned to
use for real embeddings and answer generation) isn't wired in. Instead,
I built a small local stand-in (
bedrock_mock.py) that generates a deterministic embedding from word hashes, so the full pipeline — write → embed → store → retrieve — is still demonstrable end-to-end. This means the submission doesn't meet the "at least one AWS service" requirement, which I want to be upfront about rather than overclaiming. - Getting CockroachDB's
VECTORtype to work correctly throughpsycopg2took some digging — it needs an explicit::VECTORcast on both inserts and the similarity-search query, since psycopg2 has no native adapter for the type.
What I learned
- How to design a schema where structured data and its embeddings live together instead of split across two systems — CockroachDB's vector indexing makes that genuinely simple once the type-casting quirk is sorted out.
- The value of building the storage/retrieval layer decoupled from the embedding/LLM layer — because AWS wasn't available, I could swap in a mock embedding function without touching any CockroachDB code at all.
What's next
Wiring in real AWS Bedrock (Titan Embeddings + Claude) once account access is available — the codebase is already structured so that's a one-file swap, not a rewrite.
Built With
- cockroachdb
- postgresql
- psycopg2
- python
- vector-search
Log in or sign up for Devpost to join the conversation.