Release v0.15.x planning

[adsharma]

Also see #122 for context.

• Support GQL like schema free open graphs (ANY)
  • Improve the CREATE GRAPH syntax introduced in 0.14.0 #132
• Consider removing the JSON extension and adding it to the core db
• Upgrade the JSON code. It has errors on c++26
  • Improve third_party handling (third_party: add BSD ports like system #119)
• Improve WAL
  • Add a wal_dump tool (Add wal_dump tool #116)
• Improve Arrow Support
  • Formalize the arrow export/import via a graph-std like mechanism
  • Demo with a fork of networkit or similar
  • Add python bindings
• Complete the pivot to duckdb. duckdb node table + ladybug rel table should be as optimized as native
  • Foreign table: make joins + filter etc work. The optimizer is too restrictive right now

[ritwizsinha]

Would like to work on Improving Arrow Support @adsharma if thats okay with you.

[adsharma]

@ritwizsinha #183

[vkozio]

Hi, thanks for sharing the v0.15.x roadmap.

I’ve been heavily working on the Node.js addon in a fork for a real-world project:
https://github.com/vkozio/ladybug (Node addon is under tools/nodejs_api).

From the perspective of the modern Node.js/native addon ecosystem, I think Ladybug should:

• make Node.js 20+ (LTS) the explicit baseline for the Node addon,
• upgrade the native build tooling to cmake-js 8.x and node-addon-api 8.x,
• enforce this via "engines": { "node": ">=20.0.0" } and matching CI.

Beyond just tooling, I’ve also implemented several addon-level improvements in my fork:

• a streaming API (registerStream / LOAD FROM) for feeding data from Node.js into Ladybug,
• a connection pool and ergonomics improvements for working with multiple connections,
• clearer error handling and a more approachable JS/TS API surface for application developers.

In my fork I’ve already:

• upgraded cmake-js to ^8.0.0 and node-addon-api to ^8.0.0,
• enforced engines.node: ">=20.0.0" in the Node package,
• refreshed the README and added a local changelog entry to clearly state the Node.js 20+ requirement and tooling changes,
• verified that the native addon builds cleanly with the updated toolchain and behaves correctly under Node 20+.

This brings the addon in line with the current LTS, avoids subtle build/runtime issues on older Node versions, and makes the Node.js API more practical to use in production applications.

If this direction is acceptable, I can prepare a focused series of PRs that:

• update the Node addon’s dependencies, engines and CI,
• introduce the streaming and pooling improvements,
• and document the new Node.js support policy for the Node API in the main repo.

[adsharma]

Having a more current/supported nodejs version is desirable. Yes, interested in updating. The pooling improvements look interesting too.

For streaming, did you look into the apache arrow based registering/querying? Is something like this possible in nodejs?

https://arrow.apache.org/docs/python/ipc.html

[vkozio]

Thanks for the feedback. I'll keep the Arrow question in mind and will a separate Discussion on Node.js/npm support and roadmap (tooling, streaming, pooling, Arrow alignment) so we don't overload this issue. I'll link it here when it's up.

[vkozio]

Pushed 11 PR's
Please start from #184
Suggested merge order in that PR