A few days ago, I took all my research and turned it into a blog about designing and launching a serverless federated database for AI agents.
I’ll admit — that first blog post was me squeezing all my research and ideas together under pressure.
Since then, I’ve received a lot of feedback, read even more, and refined the vision. I believe it’s now complete.
Recap
The goal has been to design, build, and ship an AI-first database that redefines retrieval for AI.
MeridianDB goes beyond semantic meaning — adding temporal, contextual, and behavioral dimensions — and aims to solve catastrophic forgetting, striking a better balance between stability and plasticity.
📄 First Iteration: Fixing AI Amnesia: MeridianDB’s Answer to Costly Training and Memory Loss
After three more iterations, the vision is now solid. I know what I can ship within the next three weeks, and I’ve made major architectural changes to the database.
Let’s ground the work and ship by Oct 7.
MeridianDB vs Existing Solutions
The most common solution today is RAG (Retrieval-Augmented Generation) — a technique that enhances LLMs by fetching external, up-to-date, domain-specific data before generating a response.
MeridianDB takes this further, expanding the dimensions of meaning for agents:
Semantic Features: Same as RAG — the agent retrieves relevant contextual data via semantic search. But not returned right away, over-fetched, and refined through Meridian DB algorithm.
Temporal Features: Goes beyond simple time-range queries:
- Data decays over time, like human memory.
- Data can be marked as factual (always retrieved if matched) or irrelevant (never retrieved).
- Frequency of access matters — both when and how often data is used.
Contextual Features: Includes user environment, task descriptions, goals — whatever context the developer thinks the agent needs to perform optimally.
Behavioral Features: Using simple decision tree and allowing the agent to log it's work on retrieval of a,b,c how that effected task x ? Simple but yet powerful behavioral analysis that can be powered by both human-in-the-loop and the AI agent.
Limitations of RAG
RAG pipelines are powerful but bring several challenges:
- Developer Complexity: You’re orchestrating multiple databases — leading to potential race conditions, ghost embeddings, and partial writes.
- Consistency & Scalability: How do you scale both your storage DB and vector search DB while keeping them in sync?
- Availability: What happens when one database fails? Can your pipeline remain highly available?
MeridianDB addresses these issues out of the box, while pushing retrieval innovation forward.
High-Level Architecture
1–2) Human clients: one driven by app logic, one for DB operators.
3) Worker API gateway: handles requests from both clients and SDK integrations.
4) Eventual consistency model: write operations are queued, simplifying retries and error handling while following Cloudflare’s consistency model.
5–8) Queues publish write events consumed by workers for vectorization and D1.
9) Retrieval engine: performs multi-dimensional queries for the AI agent.
10–14) Behavioral logging: tracks agent performance on tasks, creating a feedback loop for improvement.
No more Vector-Graph Focusing on Performance and Simplicity
The features will be stored in d1 columns rather than graphs. This allow for maximum scalability and performance.
We aren't traversing any graph, we simply hit vector database to get similarity search result, then with these over-fetched result we will perform the core concept of our new database which is ( contextual, behavioral, temporal, semantic )
The way we do this is mostly through SQL queries.
When data is fetched from vectorized. we perform a SQL query that create composed score between all the records, and letter set of number after filtering out all of the records that decayed, has low success rate when included with the result in the AI agent. Contextual are filtered out via the semantic search.
The pusedo code of the algorithm
- Fetch results from vectorize.
- Perform SQL query that filter out based on features composite score.
- Return the result to the user.
Benefits of MeridianDB
1. Integrated Consistency Model
Queue-based architecture ensures eventual consistency without developer orchestration of multiple datastores. This reduces overhead and eliminates ghost embeddings.
Data is stored redundantly (vector + D1) to maintain its multidimensional context — a tradeoff made deliberately for reliability.
2. Operational Simplicity
No need to glue together multiple systems, everything comes out of the box with great developer experience including SDK. MeridianDB as well comes with a built-in operator interface for observability, data management.
3. Native AI Feedback Loop
Behavioral logging allows for continuous improvement — even continuous learning in the future. You can measure whether retrieved context led to task success or failure through continuously updated decision trees.
4. Cloudflare-Native Scalability
- Global low-latency access, ideal for AI agents.
- Automatic retries, failover, and reliability handled by Cloudflare.
- Event-driven processing, cheap to scale.
Limitations
Eventual Consistency
Reads may lag slightly behind writes. Read-after-write guarantees may need replicas or caching strategies.
Complexity in Feature Engineering
Developers must provide contextual features (task description, environment, etc.). Future iterations could offload this to an agent that auto-generates context.
Storage Cost & Decay Model
Temporal decay means data needs periodic cleanup. This can be handled with background jobs.
Learning Curve
MeridianDB introduces new mental models (temporal, semantic, behavioral, contextual). Developers familiar with basic RAG pipelines may need time to adapt. The SDK is designed to hide most of this complexity, exposing only three core methods: store, retrieve, log. With optional methods to interact with agents, behavioral, memory and more.
Cloudflare Coupling
Cloudflare-native architecture delivers great performance — but ties you to that ecosystem.
Top comments (0)