2026 roadmap, release cadence, and PG17/PG18 support (production)

[aime-leon-dore]

Hi Apache AGE team and community,

I’m reaching out on behalf of a team using Apache AGE in production for graph workloads on PostgreSQL.

We noticed renewed activity and recent releases toward the end of 2025, which is encouraging. A prior period of lower activity led us to start planning a contingency migration in 2026 (either native PostgreSQL patterns or a dedicated graph database). We would strongly prefer to stay with AGE if we can align on long-term expectations.

Could you please share guidance on:

1. 2026 roadmap / priorities: any planned milestones (OpenCypher coverage, performance, tooling, docs)?
2. PostgreSQL compatibility: what is the support strategy and expected timeline for newer PG versions (e.g., PG17/PG18)?
3. Maintenance & releases: what cadence should users expect (minor releases, backports), and how are security fixes handled?

We can help by testing release candidates on production-like workloads and reporting regressions (and potentially contributing fixes). If there is a preferred place to discuss roadmap/support (e.g., dev mailing list), please point us to it and we’ll follow up there.

Best regards,
Yerlan

[jrgemignani]

@aime-leon-dore Sure, I will try to address these as best as possible. As there is a lot to address and unpack, I will do each point separately where applicable.

Btw, we are a small team of developers and life sometimes happens. So, I don't want to make anything sound too concrete or hold anyone to any deadline. We do our best to move forward on items as quickly and best as we can.

Adding to this, any assistance or contributions to Apache AGE is welcomed. Just remember, and I have to say this, that it is an open source project that can't pay for anything. But, we welcome anyone who wants to add contributions to, or work on, Apache AGE.

[jrgemignani]

1. 2026 roadmap / priorities: any planned milestones (OpenCypher coverage, performance, tooling, docs)?

Our roadmap or priorities (probably a better way to call it) have always been -

1. openCypher coverage
2. Performance improvements.
3. Address any issues, bugs, performance or security concerns as quickly as possible.
4. Start work on any new PostgreSQL version as soon as it is stable.
5. Releases.

Key note: Resources permitting. Like all teams, we have limited resources. We will divide our resources based on perceived priority of the current items.

We are currently working on finalizing PG18 and moving the master to PostgreSQL 18. Then we will start the next release process, from PG18 down to PG14.

[jrgemignani]

2. PostgreSQL compatibility: what is the support strategy and expected timeline for newer PG versions (e.g., PG17/PG18)?

4. Start work on any new PostgreSQL version as soon as it is stable.

PG17 has already been released. PG18 will be in the next release cycle, starting in a few weeks, when PG18 and the master are ready.

PG19 work will start, time permitting, when a stable release is ready.

[jrgemignani]

3. Maintenance & releases: what cadence should users expect (minor releases, backports), and how are security fixes handled?

The release process take a fairly long time to complete. So, we tend to wait until there is a fair amount of important work (subjective, I know) in the master before starting. The only exception to this would be security issues or significant performance or bug fixes.

When doing a release, we bring each branch up to the master branch beforehand. Unless it isn't feasible, every released branch for a specific version has all of the same additions, modifications, and deletions.

[jrgemignani]

We can help by testing release candidates on production-like workloads and reporting regressions (and potentially contributing fixes).

Everyone is welcome to vote on releases, which are sent to dev@age.apache.org
Everyone is welcome to contribute to the project.

[jrgemignani]

If there is a preferred place to discuss roadmap/support (e.g., dev mailing list), please point us to it and we’ll follow up there.

For discussions on roadmaps, I think this discussion thread is a good, public, space for it. But, dev mailing list is good too. I just prefer here, Github, because it covers the community that may not be on mailing lists.

[aime-leon-dore]

@jrgemignani Thank you for the detailed and candid response. We appreciate the clarity on the current priorities and the realistic view of the project’s release cadence.

Given this, we plan to continue using AGE in production and we’re happy to help by testing upcoming release candidates on production-like workloads and reporting regressions/issues.

We’ll subscribe to the dev mailing list and keep an eye on the release VOTE threads there. If there are specific areas you’d like community testers to focus on during RC testing (e.g., upgrades, performance regressions, OpenCypher edge cases) and any preferred details to include in reports, let us know.