Segment 1: HiddenMerit Morning Post · Issue 92

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

01｜Transwarp GPU‑Native Cognitive Database Debuts at VLDB 2026: Database Architecture Shifts from CPU‑Centric to GPU‑Centric

From August 31 to September 4, the 52nd International Conference on Very Large Databases (VLDB 2026) is being held in Boston, USA. Transwarp showcased its GPU‑Native Cognitive Database, becoming one of the highlights of the conference. The system unifies data processing and AI inference workloads on a single compute foundation, built on a GPU‑native architecture.

Unlike the common industry approach of “using GPUs as coprocessors,” the Cognitive Database starts from first principles and fully migrates the complete database pipeline – from storage I/O and query execution to result materialization – to native GPU execution. Real‑world scenarios including financial risk control, quantitative research, and business/financial analysis have demonstrated tens to thousands of times performance acceleration.

DBA Perspective: Transwarp moving the complete database to the GPU represents a paradigm revolution at the database architecture level. For DBAs, tuning dimensions will expand from “CPU core count, memory allocation, disk I/O” to “GPU video memory management, parallel stream scheduling, and data residency strategies.” This marks the shift of database architecture from “CPU‑centric” to “GPU‑centric.” Transwarp will present a report titled “GPU‑Native Cognitive Database: Built for the Enterprise, the Future Infrastructure for Deep Database‑AI Integration” on the afternoon of September 2 (local time).

02｜Dameng All‑in‑One Appears at DTCC: Deep Hardware‑Software Integration Completes AI Intelligent Computing Foundation Upgrade

At DTCC 2026, Dameng All‑in‑One Product Line General Manager Zhu Honglei provided a detailed introduction to the latest achievements of the DAMENG PAI Database All‑in‑One. Through deep hardware‑software integration, the all‑in‑one achieves breakthroughs in three dimensions – extreme storage foundation, compute offloading, and full‑stack acceleration – delivering a 50% reduction in response latency and multi‑fold to tens‑of‑fold improvements in slow SQL scenarios.

For the AI intelligent computing era, the DAMENG PAI all‑in‑one has completed a comprehensive foundation upgrade. With the DM9 multi‑modal kernel enabling unified multi‑modal data processing, distributed parallel compute power accelerating AI workloads, and three‑tiered storage balancing performance and cost, it has delivered multi‑fold to tens‑of‑fold performance improvements in real‑world scenarios such as core state‑owned enterprise transactions and securities risk control.

DBA Perspective: Dameng’s “compute offloading” technology – embedding compute engines within storage nodes, giving storage itself computational capability – is an important exploration in database architecture moving from “storage‑compute separation” to “storage‑compute integration.” For DBAs, this means the boundaries of tuning are expanding from “database parameters” to full‑stack coordination of “storage + network + compute.”

03｜MariaDB Releases Governance Framework and Contributor Data: The “Transparency” Path for Open‑Source Databases

The MariaDB Foundation published its September 2026 newsletter, formally disclosing the MariaDB Server governance framework, covering technical roles, subsystem ownership, decision‑making processes, response expectations, and continuity – moving project governance from “implicit conventions” to “documented transparency.”

On contributor data, in the first half of 2026, MariaDB plc contributed 34 developers and 807 commits, while the MariaDB Foundation contributed 7 developers and 146 commits. Notably, 40 independent contributors submitted 78 commits – together with contributions from Google Summer of Code, Amazon, Red Hat, Arch Linux, and others, forming a healthy “long tail” for the open‑source database.

On the technology front, the MariaDB 13.1 preview introduces JSON arrow operators (document->'$.customer.name'), ending the long history of relying on function calls; it also lays the architectural foundation for pluggable aggregate functions like HyperLogLog. 10.6 reached EOL on July 6; the current LTS is 12.3.

DBA Perspective: The public disclosure of MariaDB’s governance framework is an important sign of the project’s maturation. For DBAs, this means there is now a publicly available reference for “how decisions are made and responsibilities are allocated” when evaluating MariaDB. The long‑tail data of 40 independent contributors also indicates that the health of the MariaDB ecosystem is recovering.

04｜PostgreSQL High‑Risk RCE CVE-2026-14669 (CVSS 8.8): Belgian Cybersecurity Center Issues Urgent Warning

Full technical details and PoC for the PostgreSQL heap buffer overflow vulnerability CVE-2026-14669 have been publicly released. The Belgian Cybersecurity Center (CCB) issued an urgent warning on August 24, urging affected users to patch immediately. The vulnerability resides in the to_char() date/time formatting function, which fails to properly validate user‑controlled POSIX time zone abbreviation lengths when handling TZ and TZtz paths, leading to heap buffer overflow that can result in arbitrary code execution as the operating system user running the database.

Affected Versions: PostgreSQL 18 < 18.5, 17 < 17.11, 16 < 16.15, 15 < 15.19, 14 < 14.24, and 19beta2 and earlier. Fixed Versions: 18.5, 17.11, 16.15, 15.19, 14.24, and 19beta3.

DBA Perspective: The CCB has flagged this vulnerability as “capable of causing database server compromise, with attackers potentially accessing, modifying, or destroying data and disrupting database availability.” Public PoC confirms remote code execution is possible with a low exploitation barrier (authenticated users can trigger it). This is another high‑risk PostgreSQL vulnerability following CVE-2026-6472 and CVE-2026-6473 this year. DBAs are advised to immediately check versions and prioritise upgrades within the Q3 patch window.

05｜Global Graph Database Market Grows to $2.85 Billion in One Year: Graph Technology Enters Scale‑Up Phase

According to TAdviser, the global graph database market has grown to $2.85 billion over the past year. Graph database applications in social networks, fraud detection, knowledge graphs, recommendation systems, and other scenarios are moving from “proof of concept” to “large‑scale deployment,” driving continued market expansion. DB-Engines rankings show that overall interest in the graph database category continues to rise.

DBA Perspective: The rapid growth of the graph database market means DBAs need to focus on learning graph query languages (such as SQL/PGQ, Cypher, GQL). PostgreSQL 19 has already introduced support for the SQL/PGQ property graph query standard, and domestic graph databases (such as Dameng GDMBASE V4.0) are also accelerating their布局. Graph databases are moving from a “niche area” to a “mainstream data management component.”

💡 SQL Little Knowledge Point

This Issue’s Knowledge Point: What are “Storage‑Compute Separation” and “Storage‑Compute Integration”?

In the discussion of Dameng’s “compute offloading” technology, two key concepts are worth distinguishing:

Dimension	Storage‑Compute Separation	Storage‑Compute Integration
Architecture	Compute nodes separated from storage nodes	Storage nodes built with compute capability
Data Path	Compute nodes read storage data over network	Compute is completed locally in storage, reducing data movement
Typical Scenarios	Cloud‑native databases, data lakes	All‑in‑one machines, high‑performance analytics
Advantages	Independent scaling, resource sharing	Low latency, high throughput

Dameng PAI all‑in‑one’s compute offloading technology follows the “storage‑compute integration” path – embedding compute engines within storage nodes, giving storage itself computational capability. The database can tell storage “what kind of data I need,” and storage completes filtering, selection, aggregation, and other compute tasks locally, dramatically improving efficiency.

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

Segment 2: HiddenMerit In‑Depth · Issue 5

Focus on Database Frontiers, In‑Depth Analysis September 2, 2026 ｜ 1 In‑Depth Feature Article

Database’s “GPU Moment”: A Paradigm Revolution in Database Architecture, Seen Through Transwarp’s VLDB 2026 Debut

1. An Architecture Shift in Progress

From August 31 to September 4, the 52nd International Conference on Very Large Databases (VLDB 2026) is being held in Boston, USA. This year’s conference has listed “Data Systems for the AI Agent Era” as one of its core themes, with dedicated forums and workshops on Agentic Data Systems and database‑large model collaboration.

At the conference, Transwarp’s GPU‑Native Cognitive Database attracted significant attention.

The core characteristic of this product can be summarized in one sentence: the entire database has been fully migrated to run on the GPU.

This is not a “offload a few operators to the GPU” coprocessor approach, but a complete database pipeline – from storage I/O and query execution to result materialization – fully migrated to native GPU execution. The data path has been redesigned at the architecture level, significantly reducing the overhead of data movement and transfer between CPU and GPU.

2. Why “Full Migration”?

The industry’s common “GPU cooperative acceleration” approach typically only offloads a few operators (such as vector retrieval and matrix operations) to the GPU as a coprocessor. But this path has a fundamental bottleneck: data movement.

Data transfer between CPU and GPU must go through the PCIe bus, whose bandwidth is far lower than the internal bandwidth of GPU video memory and CPU memory. If a query is split into “CPU segments” and “GPU segments,” data must be moved back and forth between the two sides, with significant time wasted on transfer – resulting in very limited acceleration.

Transwarp chose a different path: having data complete the entire processing flow directly in GPU video memory. A single GPU has tens of thousands of compute cores, capable of scheduling hundreds of thousands of threads in parallel, with peak compute power on the order of hundreds of TFLOPS. Combined with HBM high‑bandwidth video memory, data transfer rates can reach several TB/s.

Starting from first principles, migrating the database’s entire execution pipeline to run on the GPU completely eliminates the overhead of repeatedly moving data between CPU and GPU. This is the meaning of “GPU‑native,” not “GPU‑assisted.”

[quads id="805"]

3. Real‑World Performance Data

Based on the above architecture, the Cognitive Database has demonstrated significant performance improvements across multiple real‑world business scenarios:

Scenario	Improvement Magnitude
Financial Risk Control	Tens to thousands of times
Quantitative Research	Significant acceleration
Intelligent Finance	Multi‑fold improvement
Enterprise Knowledge Q&A	Full AI inference workflow acceleration

The value of the Cognitive Database can be summarized along two mutually reinforcing threads. First, it enables general‑purpose data processing itself to run on the GPU, delivering tens to thousands of times acceleration in financial risk control, quantitative research, business/financial analysis, and other scenarios. Second, it further accelerates the full AI inference workflow – from document parsing and data retrieval to final result generation – with end‑to‑end improvement across every step.

For enterprise customers, this means no longer having to choose between a “fast database” and “good AI” – a single GPU‑native foundation compresses massive data analytics from days or hours to seconds, while making AI inference faster, more accurate, and more efficient.

4. Why Should DBAs Pay Attention?

Transwarp’s GPU‑native database is early empirical evidence of database architecture shifting from “CPU‑centric” to “GPU‑centric.”

Whether the GPU‑native database technology path becomes mainstream depends on three factors:

Continued expansion of GPU video memory capacity: HBM capacity doubles with each generation, already capable of holding TB‑level data
Continued improvement in PCIe bandwidth: Reducing the time overhead of data movement
Maturation of the GPU programming ecosystem: Enabling database developers to efficiently utilize GPU compute power

For DBAs, this means three directions for skill development need to be prepared in advance:

First, expansion of tuning dimensions. Traditional DBA tuning revolves around CPU core count, memory allocation, and disk I/O. GPU‑native databases will add three new tuning dimensions: “GPU video memory management,” “parallel stream scheduling,” and “data residency strategies.”

Second, restructuring of architectural understanding. Storage‑compute separation, storage‑compute integration, GPU‑native – these architectural concepts are redefining how databases are deployed. DBAs need to understand the applicable scenarios and cost models of different architectures.

Third, re‑establishment of performance baselines. On GPU‑native databases, traditional criteria for “slow SQL” may become completely invalid – queries that previously required full table scans could now complete in seconds under GPU parallel computing. DBAs need to re‑establish performance baselines and monitoring systems.

5. The Database’s “GPU Moment”

Transwarp will present a report titled “GPU‑Native Cognitive Database: Built for the Enterprise, the Future Infrastructure for Deep Database‑AI Integration” on the afternoon of September 2 (local time) at VLDB 2026.

The arrival of GPU‑native databases may come sooner than many expect.