Segment 1: HiddenMerit Morning Post · Issue 107

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

01｜Dameng Held Extraordinary Shareholders’ Meeting on September 11, All Three Resolutions Passed

On September 11, Wuhan Dameng Database Co., Ltd. (688692) held its third extraordinary shareholders’ meeting of 2026. The meeting was chaired by Chairman Feng Yucai, with all 11 incumbent directors in attendance, and lawyers from King & Wood Mallesons (Chengdu) present as witnesses.

Resolutions Approved:

2026 interim profit distribution plan
Purchase of liability insurance for the company and its directors and senior management
Reappointment of the accounting firm

All three resolutions were passed through a combination of on‑site and online voting. Related shareholders including Feng Yucai, Wuhan Mengyu Technology and other partnerships, Han Zhuzhong, and Zhou Chun abstained from voting on the liability insurance resolution.

DBA Perspective: Dameng’s consecutive shareholders’ meetings to advance governance standardisation, combined with its 2025 milestone of overtaking Oracle to top China’s database market for the first time and H1 2026 revenue of RMB 713 million (+36% YoY), demonstrate that the governance maturity and commercialisation capability of leading domestic database vendors are being validated in parallel. For DBAs, monitoring the governance developments of leading vendors helps assess their long‑term technology roadmap and ecosystem stability.

02｜PostgreSQL 19 Confirmed Delayed: 53 Features Reverted, SQL/PGQ and GROUP BY ALL Pushed to PG20

On September 16, Snowflake’s engineering blog disclosed that PostgreSQL 19 is confirmed delayed. PostgreSQL has released major versions each autumn for the past few years, but this year the code is in a heavy review cycle, with 53 features reverted since beta started in June 2025. Beta 4 is scheduled for September 24.

Main Features Reverted:

SQL/PGQ property graph queries: Tom Lane expressed “considerable concern” two weeks before the revert, noting that fixes require catalog changes that cannot be completed before v20
GROUP BY ALL: Caused incorrect results due to improper handling of ORDER BY non‑default equality semantics
ALTER TABLE MERGE/SPLIT PARTITION(S) : Long‑requested partition management feature, reverted due to design issues
Online data checksums: Unable to modify checksum settings during operation

Features Still at Risk: REPACK/CONCURRENTLY, foreign key fast‑path checks, postgres_fdw statistics import, and others may also be reverted.

The PostgreSQL core team’s target remains GA by the end of October, but delays of weeks or even months are now certain. Snowflake noted in its analysis: “AI tools are helping find more bugs, and many reverts came from deep AI‑generated reviews.”

DBA Perspective: The PostgreSQL 19 delay reflects the PG community’s “quality first” principle — preferring to revert features rather than release a flawed version. For DBAs, the PG 18 LTS support period becomes even more critical (until May 2031), and projects planning to upgrade to PG 19 need to adjust their timeline expectations. The SQL/PGQ reversion is particularly noteworthy — PostgreSQL’s property graph query landing timeline is pushed back further. DBAs needing graph query capabilities should continue evaluating standalone graph databases or wait for PG20.

03｜openGauss 7.0.0 LTS Scheduled for September 30: oGRAC Multi‑Write First Open‑Source Commercial Version to Launch Simultaneously

At DTCC 2026, openGauss community core expert Xiong Qin systematically presented the latest achievements of the “1+2” strategy and announced key version release plans.

oGRAC Multi‑Write Database Core Breakthroughs:

The industry’s first open‑source multi‑write database supporting simultaneous writes from multiple nodes while guaranteeing real‑time data consistency
Two‑node performance reached 3.5 million tpmC in December 2025
After deep optimisation of stored procedures, thread pools, and locks in 2026, TPC‑C performance jumped to 4.7 million tpmC, a 27% improvement
Combined with Kunpeng super nodes, multi‑write two‑node performance will exceed 5.7 million tpmC

Three Major AI Strategy Directions: Multi‑modal retrieval (relational/vector/full‑text/knowledge graph), Serverless database (1,000 instances launched within 5 seconds), and Agent memory system (reducing token consumption and improving task success rates).

Version Release: openGauss 7.0.0 LTS will be released on September 30, with the first open‑source commercial version of oGRAC multi‑write launching simultaneously, marking the transition of open‑source multi‑write databases from technical validation to production deployment.

DBA Perspective: oGRAC’s 4.7 million tpmC performance data provides quantitative confidence for domestic open‑source databases in core transaction scenarios. For DBAs, openGauss 7.0.0 LTS as a long‑term support release is worth including in Xinchuang selection evaluations. The Serverless database’s “1,000 instances launched in 5 seconds” capability directly addresses the AI agent scenario’s need for elastic database creation — DBAs need to pay attention to the operational model of this new architecture.

04｜MySQL 8.0 Officially Bids Farewell: Oracle Releases Final Patch, Community Governance Model Goes Live

On September 12, MySQL officially announced that the MySQL community governance model is now available, marking the entry of Oracle’s community strategy into its second phase. Meanwhile, MySQL 8.0 reached EOL on April 30, 2026, entering the extended support phase.

Core Governance Framework: Clarifies the role boundaries of contributors, committers, project leads, and the Steering Committee. Committers and project leads are open to non‑Oracle individuals, with the Steering Committee initially comprising Oracle, AWS, and Google Cloud.

Phase Three Planning: Expected to complete around October 2026, when Oracle’s own code contributions and commits will be made publicly through GitHub, allowing external contributors to complete Pull Requests and code reviews on the same platform as Oracle contributors.

AI Direction: Heather VanCura emphasised that AI has been listed as one of MySQL’s top priorities, with the team discussing native vector support and having already included MCP integration in the product roadmap.

DBA Perspective: The transparency of MySQL community governance is an important sign of the project’s maturation. For DBAs, this means there is now publicly available documentation on “how decisions are made and responsibilities are allocated” when evaluating MySQL. The roadmap for MCP integration and native vector support also indicates MySQL is extending into AI scenarios — DBAs with MySQL skills need to start understanding vector retrieval and agent data access protocols.

05｜YashanDB Shared Cluster Achieves <10 Second Automatic Recovery, Supporting Core System of a Bank in Kazakhstan

Science and Technology Daily reported that the YashanDB database system, independently developed by the Shenzhen Institute of Computing Sciences, has achieved a key breakthrough in shared cluster technology. After a fault was triggered, the data flow did not interrupt, and the fault recovery time curve rebounded sharply within less than 10 seconds, running smoothly — a key milestone for YashanDB in crossing the “financial‑grade high availability” threshold.

Technical Path: The team redesigned from the lowest‑level storage engine and transaction model, achieving full‑stack technical autonomy from cache coherency and global transaction management to cluster governance. Based on the original theory of “adaptive asynchronous parallelism,” the database cluster performance grows almost proportionally with the number of hardware nodes.

Deployment Progress: YashanDB has been applied in projects at the Digital Currency Research Institute of the People’s Bank of China, Liaoning Rural Commercial Bank, and Founder Securities, and has successfully gone live on the core system of Kazakhstan’s second‑largest commercial bank, moving from domestic core scenarios to international financial‑grade applications.

DBA Perspective: YashanDB’s measured data of “<10 second automatic recovery" provides a quantitative reference for domestic databases in financial‑grade high availability scenarios. The deployment at a Kazakh bank's core system also validates the applicability of domestic databases in overseas financial scenarios. For DBAs, this means the evaluation dimensions for domestic database selection are expanding from "feature benchmarking" to "international delivery capability."

💡 SQL Little Knowledge Point

This Issue’s Knowledge Point: What is PostgreSQL 19’s “Feature Reversion”?

PostgreSQL 19 has reverted 53 features since beta started in June 2025 — a typical manifestation of the PG community’s “quality first” principle.

Why So Many Reverts?

Reason	Typical Case
Insufficient design readiness	SQL/PGQ property graph queries: fixes require catalog changes that cannot be completed before v20
Incorrect results	GROUP BY ALL: improper handling of ORDER BY non‑default equality semantics
API change requirements	Certain features require modifying the Table Access Method API, too late for v19
AI‑assisted review finds more bugs	Snowflake notes “many reverts came from deep AI‑generated reviews”

What Reversion Means: Reversion ≠ permanent abandonment. Most reverted features will be retried in PG 20. For DBAs, this means PG 18 LTS is currently the more reliable upgrade target, and PG 19’s release and feature list still carry uncertainty.

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

Segment 2: HiddenMerit In‑Depth · Issue 20

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

Behind the PostgreSQL 19 Delay: AI Is Helping PG Find Bugs — and Helping PG Do “Subtraction”

1. A Rare Decision

PostgreSQL has maintained a “major release every autumn” cadence for years. But in the autumn of 2026, that rhythm was broken.

On September 16, Snowflake’s engineering blog disclosed that PostgreSQL 19 is confirmed delayed. Since beta started in June 2025, 53 features have been reverted. Beta 4 is scheduled for September 24, with GA still targeting the end of October, but “delays of weeks or even months are now certain.”

At a time when the database industry generally pursues “faster releases, more features,” the PostgreSQL core team made a counterintuitive choice: rather delay than release a flawed version.

2. The “Headline Features” That Were Reverted

Among the 53 reverts, several “headline features” stand out:

SQL/PGQ property graph queries. This is a key feature extending PostgreSQL into the graph database domain, allowing users to execute property graph queries using standard SQL syntax. Tom Lane expressed “considerable concern” two weeks before the revert: “I’d bet a dinner that if we release this in v19, we’ll discover bugs after release that can’t be fixed before v20.” The fix requires catalog changes — a low‑level modification that “touches one thing and moves everything” — too risky to make late in the beta phase.

GROUP BY ALL. A seemingly simple syntactic sugar, but found to produce incorrect results when handling ORDER BY non‑default equality semantics.

ALTER TABLE MERGE/SPLIT PARTITION(S) . A long‑requested partition management feature, reverted due to design issues.

Online data checksums. Unable to modify checksum settings during operation, meaning this feature cannot be correctly implemented under the current architecture.

3. AI’s Dual Role: An Accelerator for Finding Bugs, and a Driver of Reverts

Snowflake specifically noted in its analysis: “AI tools are helping find more bugs, and many reverts came from deep AI‑generated reviews. “

This is a phenomenon worth pondering. In the past, PostgreSQL’s beta testing relied mainly on community manual review and automated testing. But in the 2026 beta cycle, AI tools were widely used for code review and bug discovery — AI can generate large numbers of effective, reproducible test cases in a short time, exposing issues that human review might miss.

The results are two‑sided:

The good side: More bugs are found before release, raising PostgreSQL’s quality baseline
The other side: The speed of finding problems far exceeds the speed of fixing them, forcing many features to be reverted

Snowflake’s assessment: “In an era of ‘faster, faster, faster’ and AI racing ahead, the human rigour of the PostgreSQL core team is admirable.”

[quads id="805"]

4. Why Reversion is “the Right Choice”

From an engineering management perspective, the PostgreSQL team’s choice follows a clear principle: quality takes priority over timeline; the predictability of a release takes priority over the number of features.

PostgreSQL core contributor David Rowley proposed in the discussion that “the bar for reverting should be set lower this year,” citing reduced available development time. Bruce Momjian noted that a large amount of security/CVE fix work is squeezing out feature development time.

Behind this is a deeper trend: as infrastructure, a database’s “stability premium” far exceeds its “feature premium.” A bug introduced by a new feature could cause failures in thousands of production systems; missing a feature means users at most “wait for the next version.”

The PostgreSQL team’s choice is essentially defending an underlying industry consensus: the reliability of infrastructure cannot be traded for “release speed.”

5. Practical Implications for DBAs

Implication 1: PG 18 LTS is the more reliable upgrade target right now

PG 19’s delay and extensive feature reverts mean its feature list still carries uncertainty and its release date may be pushed back by months. For DBAs planning upgrades, PG 18 LTS (supported until May 2031) is currently the more reliable choice.

Implication 2: SQL/PGQ delay means graph query needs must be re‑planned

If your project depends on PostgreSQL’s native property graph query capability, expectations need adjusting — SQL/PGQ is confirmed delayed to PG 20. In the short term, evaluating standalone graph databases (such as Neo4j, Dameng GDMBASE) or waiting for PG20 are the realistic options.

Implication 3: Understanding “feature reversion” as the norm in the PG community

Snowflake emphasised in its analysis: “Don’t worry — the release process is working properly! This is a good thing! ” Reversion is not failure, but a quality assurance mechanism at work. For DBAs, this means when evaluating new PG versions, “which features were reverted during beta” is more worthy of attention than “which features were added during beta” — the revert list reflects which features are “not mature enough.”

Implication 4: AI is changing the cadence of database quality assurance

AI‑assisted code review and bug discovery are accelerating PostgreSQL’s quality assurance process — but also bringing a new challenge: “discovery speed > fix speed.” DBAs need to understand: future database releases may see “feature reversion” more frequently, because AI makes “finding problems” easier.

6. The Bigger Picture

The PostgreSQL 19 delay is a case study in “how infrastructure should evolve.”

In an era where AI accelerates everything, the PostgreSQL core team chose a slower, more cautious path. This is not conservatism, but a respect for the essential nature of the “database” role — a database’s reliability is its first reason for existing.

For DBAs, this means: upgrade decisions need to value “stability evidence” more than “feature lists.” A delayed but stable release is more valuable than a punctual but bug‑ridden one.