zvec

most vector databases are separate services. zvec runs inside your process.

what it is

zvec (500+ ★) by Alibaba is a “lightweight, lightning-fast, in-process vector database.” no separate server. no docker container. no infrastructure to stand up. your AI’s memory lives in the same process as your AI.

the difference between a library and a microservice might sound like an implementation detail. it isn’t.

why in-process matters for personal AI

the standard architecture for AI memory looks like this:

agent → [API call] → vector DB service → [response] → agent

this works fine at scale. it’s also a dependency chain. the vector DB needs to be running, configured, networked, and maintained. for a personal AI setup on a laptop or a Mac mini, that’s operational overhead for something that should just be a feature.

zvec’s architecture:

agent → [function call] → zvec (in-process) → [instant return] → agent

your memory is your code. it initializes when your process starts, it goes away when it stops, and there’s no infrastructure layer between your agent and its context.

what this unlocks

→ persistent session memory without a database server
→ semantic search over your notes, files, or agent history — in-process
→ the “what did I decide last week” problem, solved locally
→ no latency from network hops to a separate service

self.md angle

memory is the missing layer of the personal AI OS. most setups are context-window-only — the model knows what happened this session, nothing before. adding vector search requires either a managed cloud service (dependency) or a self-hosted DB (infrastructure).

zvec is neither. it’s a library. import it and your agent remembers things.

combined with a small local model and a tiny TTS layer, this makes the local AI stack genuinely self-contained. one process, all the pieces.

related

→ daytona — elastic execution environment for AI-generated code
→ KittenTTS — <25MB local voice layer for personal AI