Contributing

AionDB core is licensed under BUSL-1.1 with an Apache License 2.0 change license and a separate commercial license path. Contributions should keep the project easier to evaluate, test, and reason about.

The authoritative contribution policy lives at the repository root in CONTRIBUTING.md.

This page summarizes the policy for documentation readers. The root file controls if the two differ.

Contribution license

By submitting a contribution, you agree that it is licensed under the same terms as AionDB:

• Business Source License 1.1 (BUSL-1.1), with the Apache License 2.0 change license stated in the root LICENSE.

Do not submit material unless you have the right to contribute it under those terms.

Only submit material you created, are authorized to submit, or can legally submit under AionDB's license terms. Do not paste code from another project without checking license compatibility and attribution requirements.

DCO sign-off

AionDB uses the Developer Certificate of Origin 1.1 sign-off process. Add a sign-off line to every commit:

Signed-off-by: Your Name <[email protected]>

Git can add it automatically:

git commit -s

Pull requests may be rejected if commits are not signed off.

Good first contributions

• Reduced compatibility repros.
• Small SQL tests for parser, planner, executor, or pgwire behavior.
• Documentation corrections with exact commands.
• Benchmark harness improvements that preserve reproducibility.
• Bug reports with a minimal SQL script.

Good contributions make the project easier to trust. A small compatibility test with a clear expected result is usually more valuable than a broad refactor without a behavioral target.

Contribution style

• Keep changes narrow.
• Prefer explicit errors over silent fallback behavior.
• Add tests for behavior changes.
• Avoid mixing formatting, refactors, and feature work in one patch.
• Document limitations near the feature they affect.

Before changing shared query behavior, identify which stage is affected:

• parser;
• binder;
• planner;
• optimizer;
• executor;
• pgwire response;
• catalog/storage state.

That makes review easier because the expected blast radius is explicit.

Compatibility work

When reporting a PostgreSQL mismatch, include:

• AionDB commit hash.
• PostgreSQL version used as reference.
• SQL script.
• Expected output or error.
• Actual AionDB output or error.
• Driver and client version when relevant.

If the mismatch came from an ORM, capture the SQL generated by the ORM. Framework-level errors are hard to act on until they are reduced to SQL, protocol behavior, or catalog introspection.

Benchmark work

Benchmark claims need:

• exact command;
• dataset size;
• commit hash;
• machine details;
• durability settings;
• raw output.

Without those details, performance claims are not actionable.

Documentation work

Documentation changes should prefer:

• exact commands over vague instructions;
• examples that can be copied into psql;
• clear alpha limitations;
• links to related pages;
• honest tradeoffs.

Avoid adding a new page when an existing page should be completed. The documentation should feel like a product guide, not a pile of notes.

Review checklist

Before opening a change, check:

• does it alter public behavior?
• is there a test or fixture?
• does the documentation need an update?
• could a PostgreSQL driver or ORM observe the change?
• does the change introduce a new unsupported edge case?

Pull request checklist

• Commits are signed off.
• The change is narrow.
• Tests or fixtures cover behavior changes.
• Public behavior changes update the docs.
• Benchmark claims include exact commands and raw output.
• No secrets, private data, generated reports, or local data directories are included.