Segment 1: HiddenMerit Morning Post · Issue 105
Focus on Database Frontiers, Practical Insights for DBAs September 16, 2026 ｜ 5 Selected Global Breaking News
01｜Keewano Raises $12 Million, Launches World’s First “Machine Reasoning Database” KeewanoDB
On September 15, Israeli startup Keewano announced the general availability (GA) of KeewanoDB and disclosed that it has raised $12 million in seed funding, led by Hetz Ventures with participation from a16z speedrun, Remagine Ventures, DIG Ventures, and angel investors.
KeewanoDB is positioned as the world’s first database designed from the ground up for “machine reasoning.” Traditional analytical databases are designed for humans — events are stored flat as rows, columns, and pre‑computed aggregates, and any question about “the order in which things happened” requires reconstruction at query time. KeewanoDB, by contrast, stores the complete event sequence for each entity in order, allowing AI agents to read answers directly from raw data rather than reassembling them.
Key Performance Data: It can query 250 million events in about half a second, returning context‑ready results that agents can immediately reason over. Each event takes up only about 4 bytes, using a distributed multi‑shard design running in Kubernetes‑orchestrated Docker containers, leveraging vectorised instructions on standard CPUs rather than GPUs.
A Concrete Example: Keewano CEO Mark Kardashov noted, “We tried to use an AI agent to answer the question ‘Which users are following the same path as last month’s churned users?’ You can see what happened from any dashboard, but why it happened is hidden somewhere the database can’t reach.”
DBA Perspective: KeewanoDB’s “ordered event storage” design directly addresses AI agents’ data access needs — agents need to know “what happened before what,” and traditional table architectures require reconstructing order at query time, while KeewanoDB makes order a first‑class property of storage. For DBAs, this means database storage formats are shifting from “optimised for human queries” to “optimised for machine reasoning.” KeewanoDB executes Lua scripts sent by agents via the MCP protocol, pushing part of the reasoning down into the database — “the database becomes an extension of the agent.”
📌 HiddenMerit In‑Depth Preview: Today’s in‑depth article – “KeewanoDB: When Databases Start Being Designed for ‘Machine Reasoning,’ What Do DBAs Need to Know?” – will explore the technical logic of the “machine reasoning database” and new architectural choices for DBAs.
02｜Shenzhen Securities Information Procures Dameng Database for RMB 1,586,000: 13 Sets of DM8.4 Plus Data Guard
The procurement results for the “Dameng Database Procurement” project by Shenzhen Securities Information Co., Ltd. , a subsidiary of the Shenzhen Stock Exchange, have been announced. The transaction price was RMB 1,586,000 (tax inclusive), covering 13 sets of Dameng Database Management System v8.4 and Dameng Data Guard Software v9.
The procurement method was request for quotation, with candidate suppliers including Shenzhen Tengyun Zhifu Technology Co., Ltd., Shenzhen Jiaying Technology Co., Ltd., Digital China Digital Cloud Technology Co., Ltd., and Shenzhen Bocheng Yinghe Information Technology Co., Ltd.
DBA Perspective: This database procurement by a Shenzhen Stock Exchange subsidiary is further evidence of deepening financial Xinchuang “core infrastructure.” The configuration of 13 sets of DM8.4 plus Data Guard software indicates the purchaser has clear requirements for high availability and disaster recovery. For DBAs, the skill requirements for financial industry Xinchuang positions are expanding from “single‑database operations” to “clustered deployment and high‑availability management.”
03｜CNOOC AI System Officially Goes Live: Domestic Data Foundation Built on Dameng Database
Recently, the CNOOC artificial intelligence system based on Dameng Database officially went live at CNOOC headquarters. The project adopted Dameng Data Guard Cluster DMDW as the core database high‑availability solution, combined with domestic servers, domestic operating systems, and other foundational hardware and software environments, building a data support platform based on a domestic technology system.
Key Test Data: Under a TPC‑C simulated 1,000 concurrent user stress environment, the system’s failover time was controlled within 10 seconds, targeting RPO=0 (zero data loss). Test results showed that in a multi‑user concurrent environment, database cluster performance did not show significant degradation compared to single‑machine operation.
DBA Perspective: The adoption of a domestic database foundation for the CNOOC AI system is a benchmark practice for digital infrastructure upgrades in the energy industry. The test data of RPO=0 and failover within 10 seconds provides a quantitative reference for DBAs evaluating domestic database high‑availability capabilities in energy central SOE Xinchuang projects. The project reduces subsequent operational complexity through clustered deployment, which also indicates that DBAs need to build expertise in designing and operating clustered high‑availability solutions.
04｜FlowiseAI SQL Database Chain Node Directory Traversal Vulnerability (CVE-2026-91934): Database Sensitive Information Disclosure Possible
FlowiseAI Flowise up to version 3.1.3 has a directory traversal vulnerability (CVE-2026-91934, CVSS 7.4) in the SQL Database Chain Node component. Remote attackers can exploit this vulnerability to trigger directory traversal, potentially leading to sensitive database information disclosure. The official recommendation is to upgrade to version 3.1.4 to eliminate the issue.
DBA Perspective: Flowise is a low‑code AI application development platform, and its SQL Database Chain Node connects directly to databases. A directory traversal vulnerability means attackers may bypass application‑layer protections and directly access the database file system or sensitive configurations. DBAs using Flowise should work with development teams to upgrade to 3.1.4 immediately and review whether the SQL Database Chain Node’s database connection permissions have been minimised.
05｜MySQL Community Autumn Meetup New York Held Today: AI and Open Innovation Take Centre Stage
The MySQL Community Autumn Meetup New York was held on September 16, 17:30–20:00 EDT at the Chrysler Building in New York. The agenda included:
- “The Path to MySQL Open Innovation” : Heather VanCura, VP of Oracle External Standards and Community Participation, sharing the next phase of MySQL community participation, open collaboration, and roadmap transparency.
- “MySQL for AI: Present and Future” : Philip Antoniades, Oracle Global MySQL Solutions Engineering Lead, discussing MySQL 9.7 as an open‑source, privacy‑first AI runtime foundation when data must stay local or deployments need to run at the edge.
DBA Perspective: The MySQL community is making “AI” a core topic. As an LTS release, MySQL 9.7’s “privacy‑first AI” positioning directly addresses the compliance needs of industries like finance and healthcare for “data not leaving the domain.” For DBAs, this means MySQL’s role in AI scenarios is expanding from “traditional OLTP” to “edge AI data foundation.”
💡 SQL Little Knowledge Point
This Issue’s Knowledge Point: What is a “Machine Reasoning Database”?
The “Machine Reasoning Database” proposed by KeewanoDB refers to a database designed from the underlying storage format to the query method for the reasoning needs of AI agents.
Traditional Database vs. Machine Reasoning Database:
| Dimension | Traditional Analytical Database | Machine Reasoning Database (KeewanoDB) |
|---|---|---|
| Design Goal | Humans querying known questions | Machines reasoning about unknown questions |
| Storage Method | Events flattened into rows, columns, aggregates | Complete event sequences per entity, stored in order |
| Query Method | Requires reconstructing event order | Directly reads event sequences |
| Agent Support | Requires ETL pipelines and pre‑modelling | No ETL, no pipelines, direct reasoning |
| Performance | Slower with more event types | 250 million events in <0.5 seconds |
Core Design of KeewanoDB:
- Events grouped by entity: Centred on customers, devices, or transactions, keeping related events together.
- Stored in chronological order: Agents can directly see “what happened before what.”
- Reasoning pushed down to the database: Lua scripts executed via the MCP protocol, processing and filtering where the data resides, with models receiving only relevant context windows.
Implications for DBAs: When AI agents become the primary consumers of data, the traditional design paradigm of “optimising for human queries” is being replaced by “optimising for machine reasoning.” DBAs need to start understanding agents’ data access patterns — not “finding the answer to a known question,” but “exploring the context of an unknown question.”
HiddenMerit Team Production Slogan: 绩优隐于内，金石启新程 | Hidden deep. Merit bold. Forge ahead.
[quads id="805"]
Segment 2: HiddenMerit In‑Depth · Issue 18
Focus on Database Frontiers, In‑Depth Analysis September 16, 2026 ｜ 1 In‑Depth Feature Article
KeewanoDB: When Databases Start Being Designed for “Machine Reasoning,” What Do DBAs Need to Know?
1. A Database That “Grew Out” of the Gaming Industry
Keewano’s founding team came from the gaming industry. While doing data analytics at gaming companies like Plarium, they encountered a recurring problem: you can see “what happened” from any dashboard, but “why it happened” is hidden somewhere the database can’t reach.
Mark Kardashov gave a concrete example: “We tried to use an AI agent to answer the question ‘Which users are following the same path as last month’s churned users?’ You can see what each user’s last action was, but the order and context between actions — what caused the churn — traditional databases simply can’t store.”
This problem is particularly acute in the gaming industry: a player may generate massive, complex interaction histories, with each event having timestamps, attributes, and correlations. Traditional table architectures flatten these events into rows and columns, and any question about “order” requires reconstruction at query time. And reconstruction at query time means: the more data, the slower and more expensive the query.
So the team decided: start from the storage format and redesign a database built for machine reasoning.
2. KeewanoDB’s Core Design: Order is the First Property of Storage
The fundamental difference between KeewanoDB and traditional analytical databases can be summarised in one sentence: traditional databases store events scattered; KeewanoDB stores events in order.
Traditional Approach: A user’s sequence of “login → browse → add to cart → pay → churn” would be split into 5 independent records in a traditional database, scattered across different rows. When an agent asks “what happened before churn,” the database needs to find these 5 records again, sort them by time, and analyse patterns.
KeewanoDB Approach: The complete event sequence of the same user is stored together in order. When an agent asks “what happened before churn,” it directly reads that user’s event sequence — no reconstruction, no ETL needed.
Three Key Design Decisions:
Decision 1: Organise storage around “entities.” KeewanoDB is not centred on “tables” or “event types,” but on entities such as customers, devices, and transactions. All events for each entity are stored together completely.
Decision 2: Store events in chronological order. This is the most core differentiation. Traditional databases reconstruct order at query time; KeewanoDB makes order a natural property of storage.
Decision 3: Push reasoning down to the database. KeewanoDB supports agents sending Lua scripts via the MCP protocol, completing processing and filtering where the data resides. The database performs part of the reasoning first, and the model receives only the relevant context window — not the complete raw event history.
Performance Data: Approximately 250 million events can be queried in under half a second, with each event occupying only about 4 bytes. The system uses a distributed multi‑shard design, running in Kubernetes‑orchestrated Docker containers, leveraging vectorised instructions on standard CPUs rather than GPUs.
3. Why Does “Machine Reasoning” Need a Different Database?
Judah Taub, Managing Partner at Hetz Ventures, which led Keewano’s $12 million funding round, put it succinctly:
“Every wave of AI adoption exposes the layer underneath that wasn’t built for the new workload. “
Traditional databases are designed for “humans asking known questions.” A human analyst opens a dashboard, looks at a predefined metric, and decides what to do next. The database’s optimisation goal is: make queries for this known question as fast as possible.
AI agents “explore to answer unknown questions.” An agent asks “which users are following the same path as churned users” — this question has no predefined dashboard, no pre‑computed aggregates. The agent needs to look at event sequences for many users, find patterns, and then reason.
The difference between these two usage patterns directly determines that storage formats should be different:
| Usage Pattern | Humans | AI Agents |
|---|---|---|
| Question Type | Known, predefined | Unknown, exploratory |
| Data Access | Query a metric | Look at a sequence |
| Core Need | Fast queries | Accurate reasoning |
| Bottleneck | Aggregate computation | Context reconstruction |
KeewanoDB’s “ordered storage” specifically targets the “context reconstruction” bottleneck. When events are stored in order, agents don’t need to reconstruct context at query time — the context is already in storage.
4. A New Architectural Choice for DBAs
KeewanoDB’s emergence adds a new option to the DBA’s data architecture toolbox. But this is not a “replace existing databases” product — it’s a “complement”:
Scenario 1: Agent‑driven behavioural analytics. When the business needs to answer questions like “why did users churn” or “what behaviour sequences led to conversion,” KeewanoDB’s event sequence storage is more suitable than traditional data warehouses.
Scenario 2: Real‑time operational decisions. KeewanoDB’s “no ETL, no pipeline” design means there is almost no delay from data generation to queryability.
Scenario 3: Coexistence with existing data warehouses. Keewano supports Parquet and Iceberg and can ingest Kafka event streams. Enterprises can send the same events simultaneously to KeewanoDB (for agent reasoning) and Snowflake (for traditional BI).
What DBAs Need to Note:
- KeewanoDB is currently a standalone product, not “a feature added to an existing database.” Introducing it means adding a new piece of data infrastructure.
- Its pricing model is based on “active entity count” rather than event count, which may be more economical for high‑event‑volume scenarios.
- It cannot replace the role of traditional data warehouses — traditional BI, reporting, and compliance auditing still require data warehouses.
5. A Bigger Signal
KeewanoDB’s $12 million funding and its positioning as the “world’s first machine reasoning database” send a clear signal: AI agents are becoming the “first‑class users” of database design, not just “a new user type.”
Over the past two decades, the core proposition of databases has been “how to let humans query data faster.” Over the next decade, the core proposition may become “how to let machines reason about data more accurately.”
For DBAs, this means:
- Storage format choices will no longer be just “row store vs. column store,” but also “event sequences vs. flat tables.”
- Query optimisation will no longer be just “indexes and JOINs,” but also “context window management” and “reasoning pushdown.”
- Data architecture will no longer be just “data warehouse + data lake,” but may also include an “agent reasoning layer.”
One of KeewanoDB’s founders said: “In 1964, Japan didn’t try to make trains run faster on the old tracks — they built a new line. Databases are at that fork in the road right now.”
For DBAs, understanding the direction of this fork may be more important than mastering any single technology.
HiddenMerit Team Production Slogan: 绩优隐于内，金石启新程 | Hidden deep. Merit bold. Forge ahead.