📊 HiddenMerit Daily · Issue 39
Focus on Database Frontiers, Practical Insights for DBAs June 9, 2026 | 5 Selected Global Breaking News
01|MongoDB 8.3 “AI‑Native” Launches Domestically, Alibaba Cloud Fires First Shot in AI Database Race
In early June, Alibaba Cloud became the first in China to launch MongoDB 8.3. MongoDB 8.3 introduces an “AI‑Native” design philosophy – not “add‑on” AI support, but deep integration of three major capabilities – vector search, auto‑embedding, and intelligent O&M – directly into the database engine, achieving a trinity of “native search, native vectorisation, native O&M.”
The three native AI capabilities in detail:
- Native Search: Vector and full‑text search are built into the engine layer; a single pipeline completes hybrid search combining “vector + full‑text + scalar” (with
$rankFusionstage using the RRF algorithm for score fusion), eliminating the need for applications to switch between multiple systems. - Native Vectorisation: Write‑time auto‑embedding, transparent to applications, zero sync overhead; the engine layer automatically listens for data changes via Change Stream, calls models to generate vectors, writes back to documents, and triggers index updates.
- Native O&M: Natural language management, AI‑assisted slow query analysis, index recommendations, and parameter tuning, covering all versions; this capability covers all versions of Alibaba Cloud MongoDB, not limited to 8.3.
MongoDB 8.3 also delivers impressive OLTP performance: compared to version 8.0, write throughput increases by 35% , read throughput by 45% , and ACID transaction throughput by 15% , all without any application code changes.
Alibaba Cloud MongoDB 8.3’s hybrid search capability is currently in invite‑only testing, while auto‑embedding and console natural language O&M capabilities are available. Alibaba Cloud is the only cloud vendor in China that can provide the latest version of MongoDB, consistently maintaining a release cadence in sync with the open‑source version.
-
DBA Perspective: MongoDB 8.3’s “AI‑Native” design philosophy represents a high‑order form of database AI‑ification. In the past, building a RAG application required DBAs to set up complex ETL pipelines across MongoDB (business data), a vector database (embeddings), and a message queue (sync链路). Now 8.3 completes the entire chain within a single database. The “write‑time vectorisation” capability of auto‑embedding fundamentally eliminates data consistency problems, but also means DBAs must redesign the performance baseline and monitoring strategy for the write path. Moving from “add‑on AI” to “native AI” is a generational shift in database architecture.
-
CTO Perspective: Alibaba Cloud’s domestic launch of MongoDB 8.3 is another major milestone in the “AI‑Native” direction for domestic cloud databases, following Tencent Cloud’s AI‑Native 3.0 upgrade. For CTOs planning data architectures for AI applications, MongoDB 8.3’s design of “a single pipeline for hybrid search” and “zero sync overhead” can significantly reduce the data integration complexity and O&M costs of AI applications.
-
Investor Perspective: The deep cooperation between Alibaba Cloud and MongoDB, demonstrated by this domestic launch, shows that domestic cloud vendors are seizing market opportunities by introducing world‑leading AI database capabilities. MongoDB’s AI‑Native approach and domestic databases’ AI‑In‑Database approach form a competitive yet cooperative relationship. Investors should pay attention to differences in customer acceptance between these two technology paths in commercial implementation.
02|Oracle May CSPU Sounds Security Alert: REST Data Services Exposes CVSS 10.0 Perfect Score Vulnerability
In early June, the Cyber Security Agency of Singapore (CSA) and the Taipei Second District Network Center in Taiwan issued urgent alerts regarding multiple vulnerabilities fixed in Oracle’s first monthly Critical Security Patch Update (CSPU) in May. This CSPU fixed 35 vulnerabilities, of which 11 are rated Critical, with multiple scores above 9.0.
Critical vulnerability details:
| CVE ID | CVSS Score | Affected Component | Description |
|---|---|---|---|
| CVE-2026-46840 | 10.0 | REST Data Services (Backend‑as‑a‑Service) | Unauthenticated attacker can fully compromise the system via HTTPS; attack may impact other products |
| CVE-2026-46775/CVE-2026-46839 | 9.9 | REST Data Services (Core) | Low‑privilege attacker can fully control REST Data Services |
| CVE-2026-46817 | 9.8 | E‑Business Suite (Oracle Payments) | Unauthenticated attacker can fully compromise the system via HTTP |
| CVE-2026-34311 | 9.8 | Hospitality OPERA 5 | Unauthenticated attacker can fully compromise the system via HTTP |
| CVE-2026-2332 | 9.1 | REST Data Services (Core/Eclipse Jetty) | Can lead to unauthorised creation, deletion, modification, and reading of critical data |
| CVE-2026-33557 | 9.1 | Communications Unified Assurance (Apache Kafka) | Can lead to unauthorised creation, deletion, modification, and reading of critical data |
| CVE-2026-46833 | 9.0 | Database Server (Net Service) | Affects versions 23.4.0 to 23.26.2; can lead to full takeover of Net Service |
Affected Versions: Oracle REST Data Services 24.2.0 to 26.1.0, Oracle Database Server 23.4.0 to 23.26.2, Oracle E‑Business Suite 12.2.3 to 12.2.15, and others.
Special Note: CVE-2025-15467 (affecting Oracle Communications Unified Assurance) has a CVSS score of 8.8, but the vulnerability is “low complexity” and public PoC exploit code already exists – it is recommended to include it in this patch window as well.
-
DBA Perspective: CVE-2026-46840, with a CVSS 10.0 perfect score, is one of the most severe Oracle vulnerabilities in recent years. REST Data Services serves as the REST API gateway for Oracle databases. The vulnerability in its Backend‑as‑a‑Service component allows an unauthenticated attacker to fully compromise the system via HTTPS – meaning that if an enterprise exposes API interfaces through ORDS, an attacker could directly penetrate the application layer and reach the database core. The affected versions cover most current Oracle 23ai and ORDS deployments. DBAs must immediately assess affected versions and set the CSPU patch to P0 priority. The “scope changed” characteristic of CVE-2026-46833 is also worth vigilance – an attack could extend from Net Service to other affected products, potentially exceeding the expected damage radius.
-
CTO Perspective: With Oracle’s shift to a monthly CSPU mechanism, the first patch package already exposed a CVSS 10.0 vulnerability, indicating that security threat response for traditional commercial databases has become a routine, high‑priority task. The multiple vulnerabilities with scores above 9 in the CSPU are concentrated in REST Data Services and E‑Business Suite, indicating that API gateways and peripheral applications are becoming new weak points in database security. CTOs should establish a “monthly security baseline” mechanism and incorporate Oracle patches into CI/CD gates.
-
Investor Perspective: Oracle’s security maintenance costs continue to rise. In the May CSPU, REST Data Services and E‑Business Suite were the hardest hit areas. This may push enterprise customers to evaluate cloud‑native and open‑source alternatives. The urgent alerts from Singapore’s CSA and the Taiwan region further amplify this signal – regulators have designated the relevant vulnerabilities as high‑priority disposal targets.
03|Medical Xinchuang Accelerates Again: Jieyang Third People’s Hospital Procures Kingbase Database, “Software‑Hardware Integration” Becomes Standard
On June 8, the winning bid announcement for the Jieyang Third People’s Hospital HRP management system server, database (domestic products), and computer room supporting construction project was released, with China United Network Communications Co., Ltd. Jieyang Branch winning the bid for RMB 640,000.
Procurement list details:
- Database: 2 sets of Renda Kingbase KingbaseES V9, unit price RMB 80,000, total RMB 160,000
- Operating System: 5 sets of UnionTech Server OS V20
- Middleware: 2 sets of TongTech TongWeb V7.0
- Server: 1 H3C UniServer R4930 G5 (domestic chip server)
Following the China Academy of Art Xinchuang procurement reported in previous issues, this is another important medical Xinchuang implementation case. The procurement model has evolved from “single database procurement” to a full‑stack Xinchuang configuration of “domestic CPU server + domestic OS + domestic database + domestic middleware,” becoming the standard configuration for government and enterprise Xinchuang projects. The large‑scale deployment of KingbaseES V9 in a medical HRP management system further validates Kingbase’s delivery capability in the healthcare industry.
-
DBA Perspective: In Jieyang Third Hospital’s RMB 640,000 procurement order, Kingbase database accounts for RMB 160,000, UnionTech OS 5 sets, TongTech middleware 2 sets, and H3C domestic server 1 unit – this is a typical “full‑stack Xinchuang” procurement model. The DBA’s responsibility boundaries in Xinchuang projects are expanding from “managing databases” to “evaluating full‑stack compatibility.” DBAs need to simultaneously assess the computing characteristics of domestic chip servers (Kunpeng/Phytium), kernel parameter tuning of domestic operating systems, connection pool configuration of domestic middleware, and their collaborative performance with the database. KingbaseES V9’s delivery case in a medical HRP system provides a reference paradigm for medical industry DBAs in domestic replacement.
-
CTO Perspective: Medical industry Xinchuang procurement has moved from “single‑point pilot” to “batch implementation.” Although the RMB 640,000 procurement amount at Jieyang Third Hospital is modest, its “software‑hardware integration” full‑stack model is demonstrative. When planning medical Xinchuang projects, CTOs should prioritise “domestic CPU + domestic OS + domestic DB + domestic middleware” combination solutions that have complete ecosystem adaptation validation, to reduce compatibility risks from multi‑vendor integration.
-
Investor Perspective: The medical Xinchuang track is accelerating in volume. In Jieyang Third Hospital’s full‑stack procurement, the Kingbase database, at RMB 160,000 (25% of the total), is a core software expenditure item. As the Xinchuang transformation of public hospitals nationwide progresses, database vendors with “full‑stack adaptation capability” and “healthcare industry delivery cases” will enjoy obvious first‑mover advantages.
04|Sitronix Applies for Slow SQL Prediction Patent: Deep Learning Transforms DBAs from “Firefighters” to “Predictors”
On June 5, information from the China National Intellectual Property Administration showed that Beijing Sitronix Information Technology Co., Ltd. and Beijing Siyuan Pasi Information Technology Co., Ltd. applied for a patent titled “Database slow SQL prediction analysis method, device, equipment, and medium” (publication number CN122152844A).
Patent abstract highlights:
- Realtime acquisition of SQL statements and associated database environment data during database operation;
- Feature extraction based on SQL statements and database environment data to generate feature vectors;
- Slow SQL prediction using a pre‑trained slow SQL prediction model (deep learning model), generating a slow SQL probability and predicted execution time;
- When determined to be a potential slow SQL, based on the attention weight distribution generated by the pre‑trained slow SQL prediction model when processing the feature vector, determine the root cause category causing the SQL statement to be a potential slow SQL.
The patent comprehensively applies neural network technologies such as CNN, RNN, and LSTM for feature extraction and fusion analysis. Sitronix, founded in 1995 and listed on the Shenzhen Stock Exchange in 2017, is a leading provider of system solutions for the telecommunications industry.
-
DBA Perspective: Sitronix’s slow SQL prediction patent represents a paradigm shift in database operations from “passive response” to “active prediction.” Traditional slow SQL remediation is “after‑the‑fact” – a SQL runs slowly, then the DBA looks at the execution plan, adds indexes, or rewrites the SQL. An AI slow SQL prediction model can, before or at the early stage of SQL execution, predict whether it will become a slow query and identify the root cause category. For DBAs, this means that future database operations tools will have “preventative diagnostic” capabilities, and the DBA role will evolve from “firefighter” to “risk predictor.” The “root cause localisation” capability based on attention weights in the patent is particularly noteworthy – it not only tells you “it will be slow” but also “why it will be slow.”
-
CTO Perspective: Sitronix’s patent application reflects the urgent need in the telecommunications industry for intelligent database operations. When AI can predict slow SQL and provide root cause analysis, enterprises can significantly reduce business interruptions caused by performance issues. For technical teams with limited operations personnel, such AI prediction capabilities are a key lever for improving efficiency.
-
Investor Perspective: Slow SQL prediction is one of the core technologies in the database AIOps field. Sitronix’s patent application indicates that domestic IT service providers are deeply integrating AI into database operations toolchains. Investors should focus on database service providers and operations tool vendors with technical accumulation in the AIOps direction. Sitronix’s 2025 revenue was RMB 617 million, with a net loss of RMB 184 million – the commercialisation cadence of its AI operations patent is worth tracking.
05|CETC Kingware Assesses Xinchuang Deep Water: Three‑Year Evolution Roadmap from “Usable” to “Intelligent Use”
Recently, CETC Kingware (formerly Renda Kingware) published an in‑depth technical article titled “Xinchuang Deep Water: A Three‑Year Evolution Roadmap for Databases from ‘Usable’ to ‘Intelligent Use’.” The article judges that Xinchuang construction is moving from the “quantity‑meeting” shallows into the “autonomous‑control” deep water. Over the next three years, the industry will no longer be satisfied with “seamless replacement,” but will require databases to possess native intelligence, cloud‑native elasticity, and cross‑scenario data convergence capabilities.
Three Major Technology Trends:
- Kernel autonomy becomes a hard indicator: Future databases must have deep adaptation capabilities for domestic chips (Phytium, Kunpeng), not simple binary compatibility;
- Popularisation of storage‑compute separation architecture: To solve the scalability bottlenecks of traditional single‑node architectures;
- AI‑native convergence: Databases will no longer be just data warehouses, but “intelligent engines” embedding vector search and large model inference.
Three Future Scenario Predictions:
- Scenario 1: Real‑time intelligent decision‑making under high concurrency. The finance or energy sectors will face concurrent writes of massive real‑time data and millisecond‑level analysis needs. The built‑in vector retrieval capability of KingbaseES V9 enables the database to directly handle semantic search required by large models, without introducing independent vector database components.
- Scenario 2: Data mobility in multi‑cloud environments. In the future, data will flow frequently between private clouds, public clouds, and edge nodes. Kingbase’s disaster recovery solutions already support multi‑site active‑active capabilities, achieving “zero data loss” (RPO=0) and “second‑level recovery” (RTO<30s).
- Scenario 3: Unified governance of heterogeneous data sources. KingbaseES V9, through extended data type support, natively stores JSONB, XML, and large objects, and combines this with time‑series data processing capabilities to achieve unified storage and governance of multi‑modal data.
“Three‑Step” Evolution Strategy:
- Legacy migration and architecture decoupling (Year 1): Smooth migration of core systems, decoupling applications from databases;
- Capability enhancement and performance tuning (Year 2): Introduce vector retrieval to prepare the data foundation for AI business;
- Intelligent convergence and ecosystem restructuring (Year 3): Fully promote cloud‑native deployment, deeply integrate database AI capabilities with upper‑layer business.
-
DBA Perspective: Kingbase’s three‑year evolution roadmap provides DBAs with a clear career development coordinate system. The leap from “usable” to “intelligent use” means that DBAs’ skill stacks must also upgrade synchronously – from mastering “migration tool usage” to精通 “kernel‑level tuning” to possessing “AI convergence architecture design” capabilities. The “built‑in vector retrieval capability” and “unified multi‑modal data governance” emphasised in the article are the core skills DBAs must储备 over the next three years. Kingbase’s proposed “Assessment → Transition → Optimisation” three‑step strategy can serve as a standard methodology for DBAs leading Xinchuang migration projects.
-
CTO Perspective: Kingbase’s judgment that core system replacement is being elevated from a “technical problem” to a “strategic problem” is highly consistent with the government cloud selection trends we have reported in previous issues. The “three‑year evolution roadmap” proposed in the article provides CTOs with a quantitative framework for formulating Xinchuang medium‑ and long‑term plans. CTOs should focus on the two technology directions of “storage‑compute separation architecture” and “AI‑native convergence” in the article – they will directly determine the success or failure of database selection over the next three years.
-
Investor Perspective: Kingbase’s transformation from a “product supplier” to a “methodology exporter” is a sign of the maturity of the domestic database industry. The “Xinchuang deep water” judgment and “three‑year evolution” framework proposed in the article are essentially Kingbase defining industry standards and evolution cadence. Vendors with the ability to “define industry standards” will occupy stronger pricing power in the deep‑water Xinchuang replacement.
📚 SQL Little Knowledge Point
This Issue’s Knowledge Point: What is Slow SQL Prediction?
Slow SQL prediction refers to the technology of using machine learning or deep learning models to predict, before or at the early stage of actual execution of an SQL statement, whether it will become a slow query. Unlike the “post‑mortem analysis” of traditional slow query logs, slow SQL prediction pursues “advance prediction.”
Typical Technical Path:
- Feature extraction: Extract features from SQL statement text, execution plans, and database environment data (CPU, memory, I/O, etc.);
- Model prediction: Use neural network models such as CNN, RNN, LSTM to predict slow SQL probability and estimated execution time;
- Root cause localisation: Based on attention weight distribution, determine the core factors causing the slow SQL (e.g., missing indexes, outdated statistics, data skew).
Application Value:
- Proactive O&M: Intervene before the business perceives performance issues;
- Resource scheduling: Perform load isolation or rate limiting after predicting slow queries;
- Root cause analysis: Accelerate DBA fault diagnosis paths.
Sitronix Patent (CN122152844A) comprehensively applies CNN, RNN, and LSTM for feature extraction and fusion analysis, representing an important exploration of slow SQL prediction technology in the domestic database O&M field.
HiddenMerit Team Production Slogan: 绩优隐于内,金石启新程 | Hidden deep. Merit bold. Forge ahead.