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_entries table alongside its embedding, in a native VECTOR column with a vector_cosine_ops index. 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 around psycopg2 for 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 VECTOR type to work correctly through psycopg2 took some digging — it needs an explicit ::VECTOR cast 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

Share this project:

Updates