Segment 1: HiddenMerit Morning Post · Issue 94

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

01｜Ant Group Wins VLDB 2026 Industrial Best Paper: OmniTable Manages 35 PB of Corpus with a Single Wide Table, 5.6x Efficiency Boost

On September 1 (local time), the 52nd International Conference on Very Large Databases (VLDB 2026) in Boston announced the Industrial Track Best Paper award. Ant Group’s paper, “OmniTable: A Unified Wide-Table System for Petabyte-Scale LLM Data Curation and Exploration,” won the award for solving a frequently overlooked but critical stage in large model training – data preparation.

The paper reveals that OmniTable has been managing over 35 PB and more than 305 billion entries of large model training data in production, covering web, code, PDF, and SFT data domains. In a real SFT data preparation task, the end-to-end cycle was reduced from approximately 14 days to 2.5 days, and manual operation steps were cut from 45 to 12.

OmniTable’s core principle is “logical unification, physical separation” : the same data domain is presented as a logical wide table at the upper layer, while the underlying layer is split based on data scale, access patterns, and compute engines. Features are transformed from temporary computations in scripts into system assets with definitions, versions, dependencies, and lineage. The paper documents a real-world case where engineers had to handle 106 tables in a task canvas just to add one feature.

DBA Perspective: The pain points of large model data preparation are the same kind of problems DBAs face daily – fragmented data, hard-to-trace features, unclear lineage – manifested at different scales. OmniTable’s logical wide table + physical separation approach has direct reference value for DBAs designing AI data platform architectures. When 35 PB of corpus can be managed with a single logical wide table, DBAs have a reusable paradigm for governing enterprise data assets.

02｜VLDB 2026 Opens in Boston: ByteDance with 5 Papers, Transwarp GPU-Native Database Debuts

From August 31 to September 4, VLDB 2026 is being held in Boston, with concentrated signals of a paradigm shift in database research: from “how to store and query fast” to “how to make data understandable and usable by AI agents.”

ByteDance’s database team has 5 papers accepted this year, covering key-value separated storage engines, write pushdown, Agentic LLM data preparation, temporal graph community search, and GPU subgraph matching. Among them, Terark-DS has been deployed at scale on ByteDance’s storage-compute separation architecture, achieving write throughput improvements of 20.4%–63.9% and total cost reductions of 22.7%–58.6%.

Transwarp’s GPU-Native Cognitive Database is one of the conference’s notable highlights. The system fully migrates the complete database pipeline – from storage I/O and query execution to result materialization – to native GPU execution, delivering tens to thousands of times acceleration in financial risk control, quantitative research, business/financial analysis, and other scenarios. Transwarp presented 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).

University of Michigan published 5 papers at VLDB 2026, covering temporal graph mining, quantum query optimisation, LLM semantic query engines, Lakehouse Advisor, and other directions. Among them, TIMEST, a temporal graph mining CPU implementation, achieved an average 28x speedup over comparable exact algorithm GPU implementations.

DBA Perspective: VLDB 2026 sends a clear signal – GPUs are evolving from “AI accelerators” to “core variables in database architecture.” For DBAs, the boundaries 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.”

03｜Dameng H1 2026 Results: Revenue of RMB 713 Million up 36%, All‑in‑One Business Surges 519%

Dameng (688692) reported H1 2026 revenue of RMB 713 million, up 36.27% year‑on‑year; after deducting share‑based compensation, net profit attributable to shareholders was RMB 286 million, up 41.44% year‑on‑year, with growth outpacing revenue. Gross margin was 95.36% , with solid financial quality.

Core Business Highlights:

Software licensing business: RMB 657 million, up 36% year‑on‑year, with the DM9 new product delivering a performance leap, accelerating penetration into the core Xinchuang battlegrounds of government, finance, and energy.
Database all‑in‑one business: Revenue of RMB 27.12 million, up 519% year‑on‑year, with the DAMENG PAI V2.0 deeply adapting in both RAG and Agent knowledge bases (DB4AI) and intelligent O&M agents (AI4DB).

Dameng will hold its H1 2026 results briefing today (September 4) from 15:00‑16:00, with Chairman Feng Yucai, General Manager Pi Yu, and other senior executives in attendance.

DBA Perspective: Dameng’s all‑in‑one business surging 519% confirms the trend of domestic databases moving from “software replacement” to “hardware‑software synergy.” For DBAs, the all‑in‑one delivery model lowers the barrier to database deployment and tuning – pre‑integrated and pre‑tuned hardware and software reduce the DBA’s workload in hardware selection and parameter configuration.

04｜PostgreSQL August Security Update: 28 Security Vulnerabilities, 110+ Bug Fixes

The PostgreSQL Global Development Group released versions 18.6, 17.11, 16.15, 15.19, 14.24, and 19 Beta 3, cumulatively fixing 28 security vulnerabilities and over 110 functional defects.

High‑risk vulnerabilities (CVSS 8.8) include:

CVE-2026-14669: to_char() heap buffer overflow leading to arbitrary code execution
CVE-2026-14664: Regular expression heap buffer overflow leading to arbitrary code execution
CVE-2026-14670: plperl bound object heap buffer overflow
CVE-2026-14671: refint plan cache type confusion
CVE-2026-14676: pg_stat_statements heap buffer overflow
CVE-2026-14680: internal type parameter type confusion
CVE-2026-15741: EXTRACT parameter SQL injection
CVE-2026-15742: fuzzystrmatch integer overflow enabling write to nearly arbitrary addresses

Among these, the PoC for CVE-2026-14669 (to_char() heap overflow) was publicly released in late August, prompting the Belgian Cybersecurity Center to issue an urgent warning urging immediate patching.

DBA Perspective: This is the highest‑density security update for PostgreSQL in recent years. All DBAs running affected versions (18 < 18.6, 17 < 17.11, 16 < 16.15, 15 < 15.19, 14 < 14.24) are strongly advised to schedule a patch window immediately. The to_char() vulnerability is particularly urgent – any user with SQL execution privileges can trigger it, with a low exploitation barrier.

05｜Modb September Ranking: OceanBase Holds Top Spot with 884 Points, Top Five Vendors Account for 78.9% of Market

The Modb September database popularity ranking shows OceanBase firmly in first place with 884.27 points, Dameng in second with 726.08 points, and Kingware holding third with 685.02 points. PingCAP Database (formerly TiDB) ranks sixth with 472.56 points, just 1.34 points behind fifth‑place GoldenDB (473.90 points). The Frost & Sullivan report shows that during 2025H2‑2026H1, the China distributed transaction database market reached approximately RMB 5.95 billion, with OceanBase leading at 20.2%, and the top five vendors accounting for 78.9% .

DBA Perspective: The top five vendors account for 78.9% of the market, and the “candidate pool” for Xinchuang selection is rapidly shrinking. When planning skill development, DBAs will see significantly higher returns from focusing on leading products (OceanBase, Dameng, Kingbase, etc.) than from long‑tail products.

💡 SQL Little Knowledge Point

This Issue’s Knowledge Point: What is the VLDB Industrial Best Paper?

VLDB (Very Large Data Bases) is one of the three top conferences in the database field (alongside SIGMOD and ICDE), attracting top researchers and industry practitioners from around the world to submit their work.

VLDB Paper Tracks:

Research Track: Focuses on fundamental theory, algorithmic innovation, and new system architectures, emphasising academic originality.
Industrial Track: Focuses on engineering practices in large‑scale production systems, real‑world validation, and reproducible quantitative results – emphasising “this system actually works in production.”

Ant Group’s OmniTable won the Industrial Track Best Paper – it’s not a small‑scale lab test, but a system that manages 35 PB and 305 billion large model training records in real production, compressing end‑to‑end cycles from 14 days to 2.5 days. Winning this award means: this system has withstood petabyte‑scale pressure in the real world – not just a slideshow.

For DBAs, Industrial Track papers offer more practical reference value than Research Track papers – they answer not “can it theoretically be done,” but “how was it actually done in a production environment.”

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

Segment 2: HiddenMerit In‑Depth · Issue 7

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

When 35 PB of Corpus Is Managed with a Single Logical Wide Table: A Paradigm Shift in Large Model Data Governance, Seen Through OmniTable

On September 1, 2026, the VLDB 2026 Industrial Track Best Paper was awarded to Ant Group’s “OmniTable: A Unified Wide-Table System for Petabyte-Scale LLM Data Curation and Exploration.”

The problem this paper solves extends beyond academia – the data governance challenges and solutions it reveals have direct reference value for every DBA managing enterprise data assets.

1. Why Did One Feature Lead to 106 Tables?

Before training a large model, the corpus must undergo parsing, cleaning, deduplication, quality scoring, tokenisation, and sample assembly. At petabyte scale, engineering teams face not just compute bills, but also hundreds of tables, ever‑increasing features, and a few abnormal records that can force the entire batch to be rerun.

The paper documents a stark real‑world example: to add a single quality feature, engineers had to handle 106 tables in their task canvas.

Why so many tables? Traditional large model data processing typically revolves around physical tables. After a data source is ingested, parsing results are stored in one table, cleaning results in another, and quality scores, domain labels, deduplication signatures, and security tags generate even more tables or intermediate results. Web, code, PDF, and SFT each maintain their own set of pipelines. A single pipeline is not complex, but as data sources and features continue to accumulate, the maintenance burden expands rapidly.

More troublingly, tables only store results – they rarely record how those results were derived. UDFs are scattered across different codebases, with weak associations between input columns, operator versions, batch runs, and downstream training tasks. When tracing an anomalous sample, engineers often have to cross tables and scripts; when feature versions change, they must determine which historical batches need recomputation.

Isn’t this exactly the dilemma DBAs face every day? More tables, more fields, more data sources – any change can trigger a chain reaction. This is the data governance problem at large model scale.

2. OmniTable’s Solution: Logical Unification, Physical Separation

OmniTable’s design starts from a straightforward premise: make data batches and feature columns first‑class citizens, and demote physical tables to the storage implementation layer.

Its core principle is “logical unification, physical separation” : the same data domain is presented as a logical wide table at the upper layer, while the underlying layer continues to be split based on data scale, access patterns, and compute engines. Features are transformed from temporary computations in scripts into system assets with definitions, versions, dependencies, and lineage.

At the logical layer:

Each row represents a traceable data entity
Each column stores the state of a processing stage or a derived feature
_ai_unique_id_ serves as a global primary key, using the same identifier for the same data across different sources, processing stages, and feature columns
_ai_append_name_ records ingestion batches, sources, and versions

This “single table” is a logical contract, not a physical table – in production, it is divided into four domain‑specific logical wide tables (Web, code, PDF, and post‑SFT), collectively managing 35+ PB of data.

At the physical layer:

Storage is split based on data scale, access frequency, and compute engine types
Feature columns have their own versions, definitions, dependencies, and lineage records
Data and features are linked via global primary keys, not via physical table name concatenation

A single logical wide table covers what previously required 106 physical tables to piece together.

3. Results: 14 Days to 2.5 Days, 45 Steps to 12 Steps

OmniTable’s quantitative results are striking:

[quads id="805"]

35 PB, over 305 billion large model training records brought under management
Real SFT data preparation task: end‑to‑end cycle reduced from approximately 14 days to 2.5 days
Manual operation steps reduced from 45 to 12

The efficiency gain is not because “machines are faster” – it’s because engineers no longer need to add features across 106 tables. They simply add a column to the logical wide table, and the system automatically handles physical table synchronisation, version management, and lineage recording.

4. Implications for DBAs

OmniTable is a solution for LLM data governance, but its core ideas – replacing physical fragmentation with logical views, and script accumulation with asset management – offer at least four levels of insight for DBAs:

1. The scale inflection point for data governance

When the number of data sources exceeds 3, tables exceed 50, and features exceed 20, the physical table‑centric governance model breaks down. OmniTable’s logical wide table approach provides a scalable governance paradigm – not by making tables fewer, but by making engineers stop caring about how many physical tables there are.

2. The mindset shift of treating features as assets

Traditional DBAs manage “table structures” and “indexes.” OmniTable demonstrates an advanced approach: treat features (equivalent to business metric definitions) as independent assets – each with its own definition, version, dependencies, and lineage. This has direct reference value for DBAs designing enterprise data platforms.

3. Systematic lineage tracking

OmniTable achieves complete batch and feature tracking through two system fields: _ai_unique_id_ and _ai_append_name_. In enterprise data platforms, DBAs similarly need to establish mechanisms to answer: “Where did this data come from? What processing has it undergone? Who has used it?”

4. Reusable governance experience from 35 PB

OmniTable’s governance experience for 35 PB of corpus far exceeds the “scale” of most enterprise scenarios, but at the “logic” level, it is fully reusable. When DBAs face challenges such as “aligning data definitions across multiple business lines” or “tracing the root cause of data quality issues,” OmniTable’s logical wide table + asset management paradigm is equally applicable.

The significance of OmniTable winning the VLDB 2026 Industrial Best Paper is this: it proves that at large model data scale, the traditional “table‑by‑table maintenance” model has broken down – and the similar dilemmas DBAs face when managing enterprise data assets – too many tables, inconsistent definitions, broken lineage – similarly require an architecture of “logical unification, physical separation” to break through.

This approach belongs not only to large model teams, but to every DBA who is governing enterprise data assets.