Hi! Thank you for starting this discussion, I fully support all the initiatives. And would like to add a couple of thoughts.
1. Kernel upgrade +1 for the kernel Upgrade. This is a very difficult task and it cannot be solved without involving the efforts of the community. It's not even about the number of merge conflicts and the complexity of rebase, but about testing and stabilizing the database after such large-scale changes. Since we have such massive changes maybe we should change our release policy and have special stable branches. Having these branches, we need to make efforts by merging only trusted PRs into the stable branch (2.1 for example contains almost all the PRs). Right now, 2.X is the stable branch. What if we had created a 3.X before merging the PG16 rebasing kernel to the mainline? And after rebasing to PG16, we could have started a project to move to PG18. It would be great if this was an ongoing process. Additionally, it could be beneficial if we could add new developers to the project quite easily. Perhaps some tutorials from experienced developers (Max, Baobao0206, Reshke) could help us. 2. GP6/7 parity feature Cloudberry is great, but Greenplum has a vast ecosystem. It could be even more important than some performance improvements. First of all, users should be able to integrate cloudberry into their infrastructure (as a replacement for greenplum) and only then they could get improved performance. From my site of view we need: - pxf - command center - gpbackup/gprestore - major versions migrate tool - physical standby - streaming integration (kafka_fdw?) 3. Lakehouse I do not know why, but our users are mad about the Lakehouse architecture. They are ready to move to other databases and spend a lot of effort and money. To ensure that they are building a DWH on modern architecture and that their tools will continue to evolve. It will be great if we propose some solutions to work with *parquet/iceberg* from Cloudberry. In an effective manner, of course ) WBW, Leonid On Thu, Jan 29, 2026 at 11:19 AM Dianjin Wang <[email protected]> wrote: > Hi Cloudberry community, > > As we enter 2026, I’d like to start an open discussion about possible > directions and priorities for Apache Cloudberry this year. These are > personal thoughts and initial ideas, not decisions — the goal is to > gather feedback, hear different perspectives, and shape the roadmap > together as a community. > > Overall, I believe we should continue evolving along our existing > roadmap, with a clear long-term goal of moving toward graduation. > Below are some topics and directions for discussion which we should > focus on in 2026: > > 1. Kernel Upgrade > > * Complete the PostgreSQL kernel upgrade from PG14 to PG16 > * After the upgrade: > - Continuous testing and stability improvements > - Compatibility work for ecosystem components and extensions > > 2. Release > > 2.1 Release cadence & maintenance branches > In 2025, we shipped one Apache release. In 2026, I think we should > increase release frequency — Potentially targeting something like one > release per quarter (subject to community capacity and interest). > > For the 2.x series: > - Ensure users already on 2.x can receive updates and fixes > - Continue maintaining and evolving it (2.1 in the progress, possibly > 2.2, 2.3, etc.) > > 2.2 Distribution & packaging > > Provide user-friendly artifacts: > - RPM / DEB binary packages > - Docker images > > This is important for adoption — I’ve heard repeated feedback that > building from source is a barrier for many users. > > 3. CI & Engineering Infrastructure > > * Support more OS versions in CI workflows (related discussion: > https://lists.apache.org/thread/jh7fkw0mk43bdfpjm939xphmq77yx24f) > * For release branches: Binary swap CI (already supported) > * Consider ABI compatibility testing > > Strengthen CI as part of long-term stability and release quality. > > 4. Performance & Cost Efficiency > > Performance remains a key selection factor for users. At the same > time, TCO (Total Cost of Ownership) is becoming increasingly > important. We should think about: > * Performance optimization directions: PAX, vectorized execution, ORCA? > * Resource efficiency > * Lower the maintenance cost > > 5. Usability & Out-of-the-box Experience > > * Continue improving ease of use, especially integrating more > extensions into Cloudberry for better “out-of-the-box” experience > (related discussion: > https://lists.apache.org/thread/o5n45tw6ok7wqpd7wdyhdgyhzlcs5t7j) > > 6. Ecosystem Integration > > * cross-Apache ecosystem > Now the community developers are working on Cloudberry + Apache MADlib > integration. Also, there is some community interest in integrating > Apache AGE for graph processing. > * other mostly used PG extensions > > 7. Community Growth & Adoption > > We need to continue building a diverse contributor community, > identifying and supporting new contributors. > > ~~~ > > These are only starting points for discussion. Love to have more > thoughts, priorities from you: > > * What feels most important for 2026? > * What are we missing? > * What do you think would most help adoption, stability, and long-term > sustainability? > > Looking forward to your feedback and ideas — let’s shape Cloudberry’s > 2026 together. > > Best, > Dianjin Wang > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
