Hi all
Thanks for starting this discussion. Before we decide whether to move from PostgreSQL 16 to PostgreSQL 18, I think it may be useful to first step back and clarify the project priority for Apache Cloudberry. From what I can find, I do not see a 2026 roadmap for Cloudberry yet. The latest visible roadmap I found is the 2025 proposal: https://github.com/apache/cloudberry/discussions/868 Given that, I think the first question should be: what is the main goal of Cloudberry for the next stage? Is it: 1. Better performance? 2. Better stability? 3. A richer ecosystem or broader functionality? 4. Closer alignment with PostgreSQL upstream? These goals may lead to different priorities. If the goal is better performance, I do not think upgrading to PostgreSQL 18 would be as impactful as introducing a vectorized execution engine. For an MPP analytical database, vectorized execution is likely to bring more fundamental performance gains than a kernel upgrade alone. In addition, we may also get more visible improvements from continuing to optimize ORCA/planner behavior, parallel execution, runtime filters, and PAX/AO storage paths. If the goal is better stability, then I think we should be careful. A major kernel upgrade may introduce many new regressions and compatibility issues. From a quick scan of current issues and discussions, many users are still facing stability and correctness problems, for example cluster unavailable, SIGSEGV, server terminated abnormally, PAX DELETE crashes, VACUUM issues, ORCA wrong plans, interconnect errors, gpbackup/gprecoverseg problems, and upgrade/deployment issues. In that case, stabilizing the current PG16-based code and resolving existing user-facing issues may be more valuable than starting another large kernel jump immediately. If the goal is ecosystem growth or broader functionality, then I am also not sure a PG18 upgrade helps directly. In practice, another major kernel upgrade may make ecosystem work harder, not easier. Existing extensions, FDWs, drivers, backup tools, PXF, PostGIS-related work, and other integrations may need to be revalidated, adapted, or even re-integrated again. For new plugins and tools, a moving kernel target also raises the cost of integration. Here is a rough summary of what I observed from recent GitHub issues/discussions: - Stability / correctness: #1835, #1708, #1466, #1465, #1767, #1749 - Planner / ORCA / performance: #1839, #1658, #1593, #1604, #1316 - Deployment / packaging: #1709, #1734, #1200, #1075, #1838 - HA / backup / observability: #1717, #1648, #1808, #1834, #1555 - Migration / compatibility: #1816, #1371, #1175, #1129 - Ecosystem / connectors: #1705, #945, #922, #1806, #1306 - Lakehouse / streaming / AI: #1683, #1205, #1060, #1442 From this rough scan, my understanding is that open-source users are not mainly asking for a newer PostgreSQL version. Their requests seem to be more about whether Cloudberry is stable enough, easy enough to deploy and operate, compatible enough with Greenplum/PostgreSQL ecosystems, and rich enough in tools, connectors, and extensions. A newer PG kernel may be useful internally, but it does not appear to be the primary user-facing demand at this stage. So far, I do not see a strong enough reason for upgrading to PG18 just based on the current proposal. The listed benefits, such as upstream lifecycle alignment, asynchronous I/O, and parallel log processing, are interesting, but I think we need to connect them more clearly to Cloudberry’s concrete goals: performance, functionality, stability, or ecosystem adoption. I am not against tracking PostgreSQL upstream more closely. I just think we should make sure the upgrade is driven by Cloudberry’s product/community priorities, not only by the desire to follow the latest PostgreSQL version. Thanks Jiaqi At 2026-07-06 12:53:09, "Jinbao Chen" <[email protected]> wrote: >Dear Cloudberry Community, >I hope this email finds you well. >I would like to propose upgrading the Cloudberry core from PostgreSQL 16 to >version 18. >The primary goal of this upgrade is to closely align Cloudberry with the >upstream development lifecycle. By keeping our core in sync, we will not >only strengthen our ties with the PostgreSQL ecosystem but also streamline >the workflow for Cloudberry developers to contribute code back to the >PostgreSQL community. >As you may know, PostgreSQL 17 and 18 introduce numerous groundbreaking >performance features, including: > > - Asynchronous I/O > - Parallel log processing > >These enhancements hold immense value and represent milestone improvements >for Cloudberry's capabilities. >Furthermore, following a detailed preliminary investigation and research >phase, I am confident that we can accomplish this kernel upgrade within a >much shorter timeframe than initially anticipated. >I would love to gather your thoughts on this proposal. >Looking forward to your feedback. >Best regards, >Jinbao Chen
