# 📊 HiddenMerit Daily · Issue 59
> Focus on Database Frontiers, Practical Insights for DBAs
> July 21, 2026 ｜ 5 Selected Global Breaking News
## 01｜Oracle Issues Urgent Warning: July 21 Release Update to Fix Large Number of High‑Risk Vulnerabilities, Immediate Deployment Recommended
On July 13, Oracle issued an urgent security warning, strongly recommending that all customers running supported Oracle Database versions (including Oracle Database 19c and Oracle AI Database 26ai) immediately test and deploy the Release Update (RU) after its release on July 21.
Background: New frontier AI models are significantly lowering the barrier to discovering and exploiting software vulnerabilities – these models can identify weaknesses, analyse software changes, reverse‑engineer security patches, and develop potential attack paths at unprecedented speed and scale. AI models are also becoming increasingly adept at combining multiple weaknesses across the application and data stack into complex attacks, even when individual weaknesses do not themselves pose a serious risk. As a result, protecting systems solely at the network or application layer is no longer sufficient; enterprises must protect the entire technology stack.
Fixes Included in This RU: Oracle has collaborated with state‑of‑the‑art models from Anthropic and OpenAI to proactively identify and fix potential security vulnerabilities. The upcoming RU includes fixes for a large number of severe and high‑severity security issues identified through expanded testing, including:
- Oracle Database 19c RU [19.32]
- Oracle AI Database 26ai RU [23.26.3]
- Corresponding Oracle Grid Infrastructure, database client, and other applicable component updates
Action Required: Oracle strongly recommends that customers begin planning, testing, and scheduling deployment immediately so that updates can be installed on all applicable databases as soon as possible after the July 21 release. The risk is not limited to internet‑facing databases – attackers can gain access through compromised applications, credentials, users, endpoints, or other systems connected to the database. Organisations should apply updates across their entire environment.
- DBA Perspective: The urgency of this Oracle RU far exceeds that of routine quarterly updates. When the Oracle blog uses the unusually strong wording “Prepare Now” and issues a warning a full week in advance, it indicates that the magnitude and severity of vulnerabilities fixed in this RU deserve high vigilance. Oracle 19c is currently the primary version used by most commercial Oracle users, and the 23.26.3 RU also covers Oracle AI Database 26ai – meaning that security threats to AI databases are being elevated to the same level of importance as traditional databases. DBAs should immediately complete three tasks: inventory all Oracle databases and client versions, ensure production environments are already upgraded to 19c or 26ai LTS, and prioritise RU validation in non‑production environments immediately after the July 21 release.
## 02｜Apache Doris Exposes Critical Vulnerability (CVE-2026-58319, CVSS 9.1): Unauthenticated Attackers Can Access Admin API
The Apache Doris real‑time analytical database has been found to have a critical vulnerability (CVE-2026-58319, CVSS 9.1). Its frontend HTTP REST management API lacks authentication, allowing remote attackers to perform administrative operations, threatening cluster stability and data availability.
Vulnerability Details: The vulnerability stems from improper authentication checks in the Apache Doris frontend (FE) HTTP service. Certain administrative REST endpoints do not verify the caller’s identity, allowing attackers with network access to the FE HTTP port to send unauthorised administrative requests. Attackers can exploit this vulnerability to perform administrative operations, compromise cluster integrity, and even cause denial of service or cluster instability.
Affected Versions: Apache Doris versions 2.1.0 through 3.1.0‑pre are affected. The official fix is available in version 3.1.0.
Mitigation: The Apache Foundation strongly recommends upgrading to Doris 3.1.0 or higher immediately. Temporary mitigation measures include restricting network access to the FE HTTP service and placing it behind trusted network controls.
- DBA Perspective: The CVSS 9.1 rating means this vulnerability has an extremely low exploitation barrier. As a widely deployed real‑time analytical database and lakehouse acceleration engine, Apache Doris’s management API being accessible without authentication is like leaving the front door unlocked. DBAs using Doris should immediately check versions and upgrade, or implement strict network access controls on the FE HTTP port (default 8030) before upgrading.
## 03｜Transwarp Releases GPU‑Native Cognitive Database: 66x TPC‑DS Performance Improvement, Database Rebuilt for AI Agent Era
On July 18, at the 2026 World Artificial Intelligence Conference (WAIC), Transwarp released a preview of its next‑generation GPU‑Native Cognitive Database for AI agents, moving the complete database functionality – SQL analytics, vector search, graph computing, full‑text search – entirely to GPU, achieving the world’s only complete GPU‑native database.
Why a GPU‑Native Database is Needed: Transwarp founder and CEO Sun Yuanhao pointed out that the way AI is used has changed: “Previously, AI was question‑and‑answer, called One Shot. Now it has become a Loop – agents reason, act, call databases, observe results, and if something is wrong, they modify and retry.” In a single task, an agent may repeatedly call data hundreds of times. If each response is slow, the entire process stalls.
In traditional architectures, GPUs handle inference while CPUs handle data queries, with data being transferred back and forth over the PCIe bus. “Many customers have told us that a significant amount of inference time is spent waiting for data.” 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.
Core Performance Data:
- In TPC‑DS benchmarks: 66x performance improvement and 14x better price‑performance compared to Snowflake and Databricks.
- Document parsing performance improvement of 10‑30x, vector index build performance improvement of up to 50x.
- 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.
Long‑Term Memory Capability: The database has built‑in long‑term memory and session memory, enabling agents to maintain understanding across sessions, with memory accuracy exceeding 90% – surpassing mainstream open‑source memory systems in benchmarks such as BEAM 500K.
Sun Yuanhao predicted: “In the next three to five years, computers will shift entirely from a CPU‑centric to a GPU‑centric architecture.” He emphasised the word “native”: “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. Only by fully migrating the complete functionality can you achieve a speedup starting at 20x.”
- DBA Perspective: Transwarp moving the complete database to the GPU represents a paradigm revolution at the database architecture level. For DBAs, this means the dimensions of database tuning will expand from “CPU core count, memory allocation, disk I/O” to “GPU video memory management, parallel stream scheduling, and data residency strategies.” Sun Yuanhao’s prediction that “in the next three to five years, computers will shift entirely from CPU‑centric to GPU‑centric” means DBAs need to learn the architectural principles and performance tuning methods of GPU databases in advance. Notably, a 20x‑plus performance improvement is not incremental optimisation but a qualitative leap from architectural restructuring.
## 04｜Weekly Security Vulnerabilities Focus: SurrealDB Authorization Bypass (CVE-2026-63755) and SurrealDB Stack Overflow (CVE-2026-63737)
Multiple security vulnerabilities in emerging databases were disclosed this week:
SurrealDB Authorization Bypass (CVE-2026-63755) : Affects SurrealDB versions before 3.1.0. The vulnerability stems from improper ordering of security checks during query processing – the system evaluates full record data when processing WHERE conditions in SELECT statements before enforcing permission restrictions. All authenticated users (including Record and Scope users) can exploit this ordering flaw to read the full contents of any table within their authenticated database, bypassing table‑level permission checks. The most direct exploitation method is enabling the scripting feature --allow-scripting). Even without scripting, data can be exfiltrated via SurrealQL’s THROW statement and time‑based side channels. Fixed in version 3.1.0.
SurrealDB Stack Buffer Overflow (CVE-2026-63737) : Affects SurrealDB versions 3.1.4 and earlier. Authenticated users can create unbounded expression trees by submitting queries containing tens of thousands of chained operators, triggering a stack overflow during query processing and causing the entire process to abort, resulting in denial of service. Fixed in version 3.1.5.
Apache Doris Critical Vulnerability (see News 02) : CVE-2026-58319 (CVSS 9.1), unauthenticated attackers can access admin API.
- DBA Perspective: SurrealDB has disclosed two high‑risk vulnerabilities in a single week – one allowing full table data to be read by bypassing permissions, the other allowing remote denial of service. As a multi‑model database for AI and real‑time applications, SurrealDB’s security maturity is still in a “rapid iteration” phase. DBAs using SurrealDB should immediately include both CVEs in the Q3 patch window, prioritising an upgrade to 3.1.5. The Apache Doris vulnerability is equally concerning – the management API is accessible without authentication, posing a direct threat to data security for analytical database users.
## 05｜Kingware Releases 2026 Domestic Database Trend Predictions: Vector Integration and Cloud‑Native Become Core Themes
On July 18‑20, CETC Kingware published three in‑depth articles analysing 2026 database technology trends, systematically assessing the core evolution directions of domestic databases in 2026.
Trend 1: Integration of Vector and Relational Data Becomes Standard. With the rollout of large model applications, traditional relational databases must natively support vector retrieval capability. A single architecture cannot simultaneously meet the demands of high‑concurrency OLTP and complex AI inference; hybrid workload architectures will become mainstream.
Trend 2: Distributed Architecture Moves from “Optional” to “Mandatory”. In core areas such as finance and telecommunications, the scalability bottlenecks of centralised databases are becoming increasingly prominent. Future core transaction systems will widely adopt distributed transaction architectures to support linear scaling requirements.
Trend 3: Intelligent Operations Evolves from “Auxiliary” to “Autonomous”. Faced with increasingly complex heterogeneous environments, traditional manual operations are no longer sustainable. AI‑driven autonomous databases will become a key means of achieving fault self‑healing and automatic tuning, significantly reducing reliance on expert experience.
Trend 4: Cloud‑Native and AI Integration Become the New Technical Form. Simply “moving databases to the cloud” does not solve all problems – enterprises also face the multiple challenges of vector search, elastic scaling, and storage‑compute separation. Cloud‑native AI databases decouple compute and storage while embedding vector engines and adaptive tuning capabilities.
Core Judgement: In 2026, enterprise core data architecture will complete the qualitative shift from “modular assembly” to “atomic integration” – no longer needing to purchase four separate software products (“transaction database + analytical database + time‑series database + vector database”), but instead dynamically loading different engines within the same system according to business scenarios. KingbaseES V9 has already completed its architectural layout in multi‑modal data integration, HTAP hybrid workloads, and vector retrieval capabilities.
- DBA Perspective: Kingware’s three consecutive articles cover four major directions: vector integration, distributed architecture, intelligent operations, and cloud‑native AI. These judgements are highly consistent with the CAICT report’s “AI‑native evolution” direction and OceanBase’s “lakehouse‑integrated” strategy – the domestic database industry is forming a consensus framework of “vector integration + cloud‑native + intelligent operations.” For DBAs, this framework defines the core directions for future skill development: vector index maintenance, multi‑modal data modelling, HTAP hybrid workload tuning, and elastic scaling management under cloud‑native architectures.
## 📚 SQL Little Knowledge Point
This Issue’s Knowledge Point: What is a GPU‑Native Database?
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.
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 databases, 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: Transwarp achieved 66x performance improvement and 14x better price‑performance compared to Snowflake and Databricks in TPC‑DS benchmarks. 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. Only by fully migrating the complete functionality can you 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.
No comments yet