Agent Memory Is a Database Problem. We Open-Sourced the Schema.
Introducing agentic-db — a Postgres knowledge base and personal CRM you can install in one command.
The default memory layer for most agent frameworks right now is markdown files and SQLite. Your agent writes notes to disk. It reads them back. If you're lucky, there's some keyword matching.
This works fine for demos. It stops working the moment you need your agent to actually know things.
Today we're open-sourcing agentic-db — a Postgres-native knowledge base and personal CRM, installable in one command via pgpm:
It's designed to give your agents a real brain. Not a file system. Not a key-value store. A structured, searchable, queryable database with the retrieval stack already wired up.
Give your agent a brain
Most agent memory implementations are glorified text dumps. You put something in, you get it back out by name or by recency. agentic-db is different — it's a database that your agents can actually talk to.
Here's what that looks like in practice.
"Find me everyone I’ve met who works in climate tech and is based in the Bay Area."
That’s a query that combines full-text search on notes and tags, with PostGIS spatial filtering. In markdown files, this is a fantasy. In agentic-db, it’s an SQL query.
"What’s the most relevant context from my last 50 conversations about this deal?"
Vector search via pgvector. Your agent embeds the question, runs a semantic similarity query against stored interactions, and retrieves the most relevant context — ranked by meaning, not by timestamp.
"Did I ever talk to someone named Kristofer? Or Kristopher? Or Chris?"
Trigram fuzzy matching via pg_trgm. Typo-tolerant name search that actually works, because a CRM that can’t handle name variations is barely a CRM.
"Show me every company I’ve tracked that raised a round in the last 90 days and is in the AI infrastructure space."
Structured data plus full-text search plus temporal filtering. This is what relational databases were built for — and what flat files will never do without stuffing your entire knowledge base into the context window and praying.
That’s the dirty secret of markdown-file memory. It doesn’t search. It loads. Every query is a brute-force dump of everything your agent has ever written, crammed into the context window and handed to the LLM to sort through.
It’s like a library with no Dewey Decimal System — you have to walk every aisle, pull every book off every shelf, and flip through every page just to answer a single question about one paragraph. By the end, your feet hurt, your arms are sore, and you’re exhausted... all to find one tiny piece of information!
agentic-db answers these queries at the database level. No context window bloat. No token burn. The database searches, filters, and ranks — and your agent gets back exactly what it needs.
What's inside
agentic-db bundles five capabilities into a single installable Postgres schema:
- Vector search via pgvector — embeddings stored natively in Postgres, semantic similarity queries running against the same database as your structured data. No sidecar vector DB. No sync job.
- Full-text search via
ts_vectorandts_query— keyword search configured out of the box, with ranking, stemming, and language support that's been production-tested in Postgres for decades. - Trigram fuzzy matching via
pg_trgm— approximate string matching for the real world, where people's names are misspelled and your agent still needs to find them. - PostGIS spatial queries — geographic filtering for contacts, companies, events, service areas. If your agent needs to reason about location, it's native.
- Auto-embedding triggers — insert or update a row, and the embedding pipeline fires automatically. No cron job. No external service watching for changes. The database handles it.
All of it defined in SQL. Installed as a pgpm module. Version-controlled, reproducible, composable with other Constructive packages.
agentic-db is a local development tool. It's meant to run on your machine, for your agents, against your data. While we will be deploying a commercial version with compiled row-level security policies from Constructive that can be deployed to the cloud, this one is meant to be run locally on your own machine.
Why Postgres, not another vector DB
There's a version of this story where you stitch together Pinecone for embeddings, Elasticsearch for full-text search, and Postgres for structured data. Three systems, three sync strategies, three failure modes, three bills.
Postgres can do all three. It's had the extensions for years. What it hasn't had is a clean way to package them together into something you can install in one command and start using immediately.
That's what agentic-db does.
One pgpm install and you have a schema with vector search, full-text search, spatial queries, fuzzy matching, and auto-embedding triggers running inside your existing Postgres instance. It resolves dependencies. It's versioned. It composes with other pgpm packages.
Compare that to the current workflow: clone a repo, read the README, run a migration script, hope the dependencies don’t conflict, manually configure extensions, debug the parts that assume a different hosting environment.
Give your OpenClaw a brain
If you're running OpenClaw, CrewAI, LangGraph, or any multi-agent framework, you already know the memory problem. The default persistence layer works for single-agent demos. It doesn't work when you need agents to share knowledge, search across a real corpus, or retrieve context that's older than the current session.
agentic-db is the upgrade path. Point your agent's memory at Postgres instead of local files, and suddenly it can do semantic search across everything it's ever stored, fuzzy-match names and entities, filter by geography or time, and combine structured queries with natural-language retrieval.
Your agent goes from "I can remember what you told me five minutes ago" to "I can search, filter, and reason across everything I know." That's not a minor upgrade. That's the difference between a chatbot and a tool that's actually useful.
Try it
Stop making your agents read markdown files. Give them a database that can actually answer questions.
And when the project outgrows one developer on a laptop — when it needs real users, real tenants, and real data boundaries — we built the next layer for that too.
Links
Constructive is secure-by-default Postgres infrastructure for multi-tenant SaaS and enterprise AI applications. Our open-source ecosystem powers the infrastructure behind platforms like Supabase, Neon, and more — with over 100 million npm downloads. Learn more at constructive.io.