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.
Tabular Data for Features No more Graph RAG
With the aim of maximizing scalability and performance, features will be stored in D1 columns.
In MeridianDB, we avoid traditional graph traversal as required in a Graph RAG implementation. Instead, we use a more efficient approach:
Perform a similarity search on the query, intentionally over-fetching results.
From the over-fetched set, extract document IDs and run an SQL-based filtering query in D1.
Apply user-defined functions to compute a composite score for each result, considering contextual, behavioral, temporal, and semantic dimensions.
Return the highest-scoring results to the user.
Pseudocode:
- Fetch results from Vectorize.
- Run an SQL query in D1 to filter by composite score ( behavioral, contextual, temporal, semantic ).
- Return the filtered results 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)