📊 HiddenMerit Daily · Issue 61

Focus on Database Frontiers, Practical Insights for DBAs July 24, 2026 ｜ 5 Selected Global Breaking News

01｜DB-Engines July Ranking: Oracle Decline Accelerates, Snowflake/Databricks Show Strong Growth

The July DB-Engines ranking is out, continuing the structural changes in the database leaderboard. Oracle continued its decline (monthly -7.67, annual -84.69), followed closely by MySQL (monthly -9.83, annual -94.27). Although PostgreSQL saw a slight monthly decline of -0.43, it still maintained positive annual growth of +6.92, further widening the gap with SQL Server.

Rising Forces Worth Watching:

Databricks rose to #7 (monthly +6.50, annual +56.04), jumping 5 positions from #12 a year ago – one of the fastest-growing platforms on the ranking.
Snowflake remained steady at #6 (annual +39.89), continuing to solidify its leading position among cloud data warehouses.
ClickHouse rose to #26 (annual +6.73), performing strongly as an open-source OLAP database.

Open Source vs. Commercial: MySQL (846 points), PostgreSQL (688 points), and MongoDB (387 points) lead the open-source camp, while Oracle (1132 points), SQL Server (699 points), and Snowflake (216 points) lead the commercial camp.

DBA Perspective: The strong growth of Databricks and Snowflake confirms that “lakehouse integration” and “cloud data platforms” have become mainstream directions for enterprise data architecture. The DB-Engines ranking remains an important reference indicator for DBAs when evaluating the long-term vitality of technology stacks.

02｜Dameng DM9 Appears at Lianhuashan AI Conference: “Database + AI” Dual‑Drive, Building the AI Foundation

On July 22-23, the 2026 Lianhuashan AI Conference, hosted by Huazhong University of Science and Technology, was held in Ezhou, Hubei. Dameng Data showcased its next-generation core product DM9 at the conference’s opening innovation exhibition, presenting its “Database + AI” dual‑drive strategic layout.

DM9 Core Capabilities:

Deep AI-Native Integration: DM9 deeply integrates AI capabilities, achieving continuous breakthroughs in shared storage clusters, distributed architecture, compute-storage parallelism, and resource management, with comprehensive improvements in stability, compatibility, versatility, and usability.
Dual AI Agents: Provides both O&M agents and development agents, giving the database an “AI brain” – one agent automatically monitors and proactively identifies issues, while the other enables ordinary users to query data using natural language, significantly lowering the usage barrier.
Seamless Hybrid Architecture Switching: Uses a single self-developed kernel, enabling seamless switching between centralised and distributed architectures. Business scaling is achieved by adding or removing nodes, and a built-in resource manager allows a single database to handle two types of core workloads.

Dameng has previously proposed a dual “AI for DB” and “DB for AI” development strategy. In April this year, the company released four core products for the AI era: DM9, the next-generation database all-in-one machine, Qiyun Database V4.0, and the graph database GDMBASE V4.0.

Dameng Deputy General Manager Liu Zhihong stated at a concurrent event that Dameng has made full technical preparations for the AI era and looks forward to actively participating in the AI industry ecosystem, contributing to talent co-education, technology co-research, and成果 sharing.

DBA Perspective: DM9’s dual AI agents – O&M agents for automated inspection and troubleshooting, and development agents for natural language SQL generation – directly address the two core pain points for DBAs in the AI era: heavy O&M burdens and diverse data retrieval demands. Seamless hybrid architecture switching means DBAs can dynamically adjust deployment modes based on business workloads, without being locked into either centralised or distributed after a “one-or-the-other” choice. Dameng’s dual “AI for DB” and “DB for AI” layout provides clear directional guidance for DBAs’ skill evolution in the AI era.

03｜Transwarp GPU‑Native Cognitive Database: 66x TPC‑DS Performance Improvement, General Availability by Year‑End

In July, at the 2026 World Artificial Intelligence Conference (WAIC), Transwarp released a preview of its next-generation GPU‑Native Cognitive Database for AI agents. The core breakthrough lies in moving the complete database functionality – SQL analytics, vector search, graph computing, full‑text search – entirely to run on the GPU, rather than merely offloading a few operators as coprocessor acceleration.

Why a GPU‑Native Database is Needed: The working mode of AI agents has evolved from “question‑and‑answer” to “reasoning loops” – in a single task, an agent may repeatedly call data hundreds of times. In traditional CPU‑GPU architectures, GPUs handle inference while CPUs handle queries, with data being transferred back and forth over the PCIe bus. A significant amount of time is wasted on “data waiting.” A single CPU typically has only a few hundred compute cores and approximately 400GB/s memory bandwidth, while a GPU has tens of thousands of parallel compute units and several TB/s of high‑bandwidth video memory.

Core Performance Data:

In TPC‑DS SF1000 benchmarks: completed 99 queries with a 100% pass rate; 70x performance improvement over mainstream open‑source databases; 66x over Snowflake and Databricks, with 14x better price‑performance.
In TPC‑H SF1000 benchmarks: 28x performance improvement.
On the same 100GB standard dataset, a well‑known cloud data platform took over 6 minutes, while Transwarp’s product took only 10 seconds – a 40x gap.
In a full‑chain credit analysis scenario with 480 million detailed records, performance improvement reached 449x; in an intelligent investment research scenario, improvements ranged from 30x to 5881x.

General Availability Timeline: Sun Yuanhao stated that after the preview release, customer testing applications have been opened, and the general availability version is expected to go live by the end of 2026.

Transwarp founder and CEO Sun Yuanhao emphasised “full migration” rather than “partial acceleration”: “If you only offload a few operators to the GPU as a coprocessor, the bottleneck is still data transfer and scheduling, and the speedup is only 1.5x. GPUs are more expensive than CPUs – a 1.5x speedup is not economical. You must completely rewrite the entire execution engine, storage management, and transaction processing so that database computation is completed directly in GPU video memory.”

DBA Perspective: Transwarp moving the complete database to the GPU represents a paradigm revolution at the database architecture level. For DBAs, the dimensions of tuning will expand from “CPU core count, memory allocation, disk I/O” to “GPU video memory management, parallel stream scheduling, and data residency strategies.” A 20x‑plus performance improvement is not incremental optimisation but a qualitative leap from architectural restructuring. Sun Yuanhao’s timeline – general availability by the end of 2026 – means DBAs need to accelerate their knowledge of GPU database architecture over the next six months.

04｜Weekly Security Vulnerabilities Focus: Redis Authentication RCE (QVD-2026-44936), Apache Fineract Three SQL Injections

Multiple high‑risk database‑related security vulnerabilities were disclosed this week:

Redis Authentication RCE (QVD-2026-44936, CVSS 8.8) : This vulnerability is a bypass variant of CVE-2026-25589, stemming from a memory release logic flaw when Streams consumer groups process shared NACKs, leading to a double-free vulnerability. Attackers can use commands such as XGROUP, XACK, and RESTORE to craft special payloads triggering memory corruption, ultimately achieving arbitrary code execution and gaining control of the server host. Affects Redis versions 6.2.22, 7.4.9, and 8.6.4. PoC and technical details have been publicly disclosed.

Apache Fineract Three SQL Injection Vulnerabilities (CVE-2026-57821, CVE-2026-56287, CVE-2026-35152) : Affects the open-source core banking platform Apache Fineract version 1.14.0 and earlier. Among them, CVE-2026-35152 has a CVSS score of 8.8. Attackers require an authenticated user identity with specific privileges, but once exploited, they can read sensitive database information and even read local files on MySQL and MariaDB servers via the LOAD_FILE() function. Apache has released version 1.15.0 to fix the issues.

DBA Perspective: The PoC for the Redis vulnerability has been publicly disclosed and affects three versions – 6.2.22, 7.4.9, and 8.6.4 – meaning a large number of production Redis instances may face direct threats. DBAs should immediately check Redis versions and upgrade to 8.8.0 or higher if affected, or mitigate by using ACL/rename-command to disable dangerous Stream commands (XADD, XGROUP, XREADGROUP, XACK, etc.). The Apache Fineract SQL injection vulnerabilities remind DBAs that even when applications use ORM or frameworks, concatenation of dynamic fields such as ORDER BY can still become injection entry points.

05｜CAICT Report: Domestic Databases Enter Core System Breakthrough Phase, AI‑Native Becomes Main Theme

In July, the China Academy of Information and Communications Technology (CAICT) released the “Database Development Research Report (2026)” at the 2026 Trustworthy Database Development Conference. The report notes that domestic databases have basically completed peripheral system replacement and have officially entered the critical business system breakthrough phase.

Key Data:

The global database market reached $131.6 billion in 2025; the Chinese database market reached $9.49 billion, expected to reach RMB 97.974 billion by 2028, with a CAGR of 13.06%.
The 2025 Chinese public cloud database market reached RMB 44.265 billion, up approximately 15.2% year‑on‑year.
There are 394 database product providers globally, with China (150) and the US (94) leading in vendor count.
After rapid growth from 2022 to 2024, the number of domestic database products significantly declined in 2025, stabilising and rebounding to 182 products in 2026, with a clear head‑concentration effect.

Report Core Judgements: Driven by the AI wave, database technology is accelerating its evolution toward the AI‑native direction, and the global database industry is entering a new phase of landscape restructuring. The role of databases is upgrading from “underlying support systems” to “core engines enabling intelligent decision‑making and business innovation.” Data‑intensive industries such as finance, telecommunications, and energy have already adopted a pragmatic approach of tiered deployment and differentiated selection. Domestic databases are moving from peripheral replacement into the core system deep‑water zone, and evolving toward full‑stack collaboration and intelligent operations.

DBA Perspective: The CAICT report provides DBAs with a macro‑level industry coordinate system. The “head‑concentration” signal in database product count means the window for DBA technology stack selection is narrowing – focusing on leading vendors’ technology stacks is the better choice. With domestic databases entering the “core system breakthrough phase,” DBA skills must upgrade from “basic operations” to “multi‑modal data processing and mixed‑load tuning under AI‑native architectures.”

📚 SQL Little Knowledge Point

This Issue’s Knowledge Point: What is a GPU‑Native Database?

[quads id="805"]

A “GPU‑Native Database” refers to a database where the complete functionality – including SQL analytics, vector search, graph computing, full‑text search – is fully migrated to run on the GPU, rather than merely offloading a few operators to the GPU as a coprocessor for acceleration.

Why Do AI Agents Need GPU‑Native Databases?

The working mode of AI agents has evolved from “question‑and‑answer” to “reasoning loops” – in a single task, an agent may repeatedly call data hundreds of times. In traditional CPU‑GPU architectures, GPUs handle inference while CPUs handle queries, with data being transferred back and forth over the PCIe bus. A significant amount of time is wasted on “data waiting.” A single CPU has only a few hundred cores and approximately 400GB/s memory bandwidth, while a GPU has tens of thousands of parallel units and several TB/s of video memory bandwidth.

Traditional Architecture vs. GPU‑Native Architecture:

Dimension	Traditional CPU Database	GPU‑Native Database
Compute Cores	CPU (hundreds of cores)	GPU (tens of thousands of parallel units)
Memory Bandwidth	~400GB/s	~several TB/s
Data Path	PCIe transfer between CPU and GPU	Data directly resides in GPU video memory
AI Agent Support	Data transfer becomes bottleneck	Query results feed directly into inference

Transwarp’s Implementation: In TPC‑DS benchmarks, Transwarp’s GPU‑Native Database achieved 66x performance improvement and 14x better price‑performance compared to Snowflake and Databricks. Sun Yuanhao noted: “If you only offload a few operators to the GPU as a coprocessor, the bottleneck is still data transfer, and the speedup is only 1.5x, which is not economical. You must fully migrate the complete functionality to achieve a speedup starting at 20x.”

Significance for DBAs: A GPU‑native database means the dimensions of DBA tuning will expand from CPU cores, memory allocation, and disk I/O to GPU video memory management, parallel stream scheduling, and data residency strategies.

HiddenMerit Team Production Slogan: 绩优隐于内，金石启新程 | Hidden deep. Merit bold. Forge ahead.