KeewanoDB Ditches Joins Entirely, Betting Agents Need Full Event History, Not Aggregates

If you've built retrieval or analytics pipelines for agents, you've probably hit this wall: your database knows what happened, but not why. Traditional systems flatten events into rows and precomputed aggregates, which is great for dashboards but terrible for an agent trying to reason about causality. By the time an agent queries a warehouse or search index, the sequence that would explain the "why" is already gone.

Keewano is trying to fix that at the storage layer instead of bolting on a workaround. On Tuesday the company launched KeewanoDB generally, along with $12 million in seed funding led by Hetz Ventures. It's running as a fully managed service on Google Cloud for now, with other clouds and self-managed deployment slated for early 2027.

The core idea is simple to state and unusual to implement: keep the event sequence intact rather than discarding it at write time. Agents connect directly to KeewanoDB and read that sequence where it already lives, wired through an SDK and the Model Context Protocol (MCP), the emerging standard for letting models call external tools and data sources. There's an optional analytics layer on top, including a natural language query agent and a second agent called Signal that runs anomaly detection and causal inference roughly once an hour.

"Agents and machines are becoming heavy data consumers, and they need different things than before," Keewano co-founder and CEO Mark Kardashov told VentureBeat.

Why Entity-Keyed Storage Instead of Joins

Databases have stored events plenty of ways before, graphs, tables, time-series formats. None of them fit what co-founder and CTO Pavel Bibergal needed. Bibergal previously ran data infrastructure at Plarium, a cross-platform gaming company, and according to Kardashov, his team started building with agents and LLMs roughly two years ago. Even with a big budget and a full analyst team, they couldn't get simple questions answered in real time. Standard warehouses could tell them what happened. They couldn't answer why, not at a cost the business could actually sustain. That gap is what pushed Bibergal to leave and build KeewanoDB's first prototype solo.

That origin explains why Kardashov resists easy labels for the product. He'll acknowledge it shares concepts with graph, document, and time-series databases, but pushes back on being pigeonholed as any one of them. Asked how it stacks up against a time-series database like InfluxDB, he called it an event-series database instead, a distinction that turns out to matter architecturally.

Here's the key structural choice: KeewanoDB doesn't time-order rows across a bunch of tables. It treats each entity, a user, a device, an agent, as a primary key. Every event tied to that entity attaches to it in sequence. The result is effectively one large table per entity, rather than a system built around joining many tables together. No cross-entity joins in queries, period.

Three pieces make up the architecture:

• Storage format. Events are stored as four-byte units on disk, sequenced by entity rather than split across relational tables. No joins.
• Semantic layer. Built during ingestion using LLMs, this layer attaches context to each event as it lands. Crucially, that context doesn't overwrite prior states, it appends to the stream. If a user goes from active, to inactive, to flagged for fraud, all three labels persist in sequence. An agent sees the current status without losing the history that led there.
• Query path. An acceleration engine lets agents run scripts directly inside the database through MCP, cutting out the step most agent architectures still need: shipping data out to an external process before it's usable.

That last point is worth sitting with. Most agent stacks today still treat the database as a passive store and do the actual reasoning elsewhere, which means data movement, latency, and another system to keep in sync. KeewanoDB is betting that pushing computation into the database, rather than pulling data out of it, is the more durable pattern as agents become the primary consumers of that data.

Keewano isn't alone in rethinking the database for agents, though most competitors are extending existing engines rather than starting fresh. In March, Oracle converged vector, JSON, graph, relational, and spatial data into a single transactional engine, arguing that syncing agent context across separate systems breaks down under production load. Couchbase made a similar case in June, leaning on its caching and transaction roots as a better foundation for persistent agent memory than tools originally built for search or analytics.

Philip Russom, a distinguished analyst at IronSpark Analysis, sees the real differentiator as native machine learning. Most commercial database systems, from established vendors like Oracle and Microsoft to newer ones like Snowflake and Databricks, bolt ML functionality onto a relational core. That means structured data has to be transformed before it's usable for ML, and the ML processing usually runs outside the DBMS entirely, which burns time and compute moving data back and forth.

"To be honest, I can't quite pigeonhole KeewanoDB yet," Russom told VentureBeat. "So far, it seems like a mashup of graph, neural net, time series, in-memory, and real-time DBMS types. It's definitely not JARD [just another relational database] or YAPI [yet another Postgres iteration]."

The stakes here aren't academic. VentureBeat's own Pulse Research surveyed 101 enterprises with more than 100 employees in July 2026 and found 68% said their AI agents had produced confident but wrong answers in the past six months, traced back to missing or inconsistent business context rather than model error. Recurring failures, at 37%, outpaced one-off incidents at 32%. Context gaps aren't a rounding error, they're the dominant failure mode.

Key Takeaways

Whether an event-series database, a time-series system, or a retrofitted relational database is the right call depends entirely on your workload, and KeewanoDB won't be the answer for every team. But the diagnostic question is a useful one regardless of what you end up choosing: how do your agents get event history today? If it's reassembled from a warehouse or search index at query time, or pulled from precomputed aggregates that already dropped the sequence, that's the specific gap Keewano is describing, and it's worth figuring out how much that gap is actually costing you.