Compatibility Matrix

Status: Current component-version baseline, verified from the official TeaQL version endpoint on 2026-07-15. It is not yet a complete support-lifetime contract.

This page separates versions mentioned in current documentation from versions that have been tested together. A version appearing here does not imply a support lifetime unless the row explicitly says so.

Newer executed database evidence

The 2026-08-12 Polyglot Runtime and Database Matrix is newer than the July Golden Path baseline below. It verifies generated API execution for six language runtimes and a nine-database Java matrix. Those development-branch results supersede the July provider-execution blockers for the recorded commits, but they do not imply that every fix is present in the latest published artifact.

For the concise current baseline, see Latest Versions.

For adoption decisions, use the stack-specific Java Compatibility Guide, Rust Compatibility Guide, and Database Provider Compatibility.

Metadata	Value
Authority	Generated dependency sets, released artifacts, runtime workspaces, and clean golden-path builds.
Scope	Generator, Java runtime, Rust runtime, host frameworks, and providers.
Verified version	Generator Server 20260813.231514; teaql-java 1.528-RELEASE; teaql-rs 4.2.10; cargo-teaql 2.0.11.
Verification	Run the Java and Rust golden paths in clean environments and preserve dependency/build evidence.
Update trigger	Generator, runtime, CLI, framework, toolchain, database, or provider release.

Current Documented Evidence

Component	Version mentioned by current docs	Evidence level	Support conclusion
Generator Server	20260813.231514	Official TeaQL latest-version endpoint.	Current server baseline; generated output still requires build verification.
TeaQL Java runtime artifacts	1.528-RELEASE	Official TeaQL latest-version endpoint and remote Maven resolution.	Current Java baseline. Framework/artifact combinations still require clean-build evidence.
TeaQL Rust workspace	4.2.10	Official TeaQL latest-version endpoint and crates.io publication.	Current Rust baseline. Provider/toolchain combinations still require clean-build evidence.
cargo-teaql	2.0.11, latest crates.io release observed on 2026-08-13.	Client/version checks and maintained command contracts.	Current client baseline; generated targets still require build verification.
TeaQL Maven plugin	1.1.0, built, installed, and inspected on 2026-07-13.	generate, eval, list-services, ping, show-config, and help are present; generate accepts a dynamic service target.	The live service catalog reported server version 1.1.0; the separate latest-version endpoint does not return the plugin artifact version.
Java language level	Java 21 emitted by java-lib-core on 2026-07-13.	Generated Maven compiler properties from a live plugin 1.1.0 run.	Observed for this target and date; other targets still require verification.
Rust toolchain/MSRV	Generated crates use edition 2021; Golden Path compiled with Rust/Cargo nightly 1.99.0.	Clean cargo test and console start on 2026-07-13.	Tested toolchain, not MSRV evidence; the minimum supported Rust version remains undefined.

Runtime and Generator Alignment

Generated target	Generator/client	Runtime dependency rule	Verified combination
Java java-lib-core	TeaQL Maven plugin 1.1.0, dynamic target	Generated Maven project used Java 21, Spring Boot 4.1.0, and TeaQL 1.525-RELEASE.	Evaluation, generation, and a field-change regeneration diff passed on 2026-07-13. Build is blocked by two template/runtime alignment defects described below.
Rust rust-lib-core and rust-app-console	cargo-teaql 2.0.8, dynamic targets	Generated edition 2021 crates used TeaQL runtime/provider 4.1.1, SQLite, and rusqlite 0.32.	Evaluation and both generations passed; library/application cargo test, console start, an intent-declared query, and an audit_as child mutation passed on 2026-07-13. Application output must be beside rust-lib-core because its manifest uses ../rust-lib-core/lib.

Live Dynamic-Target Findings

The plugin 1.1.0 service catalog was queried on 2026-07-13. It advertised java-lib-core, java-app-console, java-web-micronaut, java-web-quarkus, and java-web-spring-boot, among other services. Catalog presence proves discoverability, not that every server template currently completes successfully.

The same clean verification found these current boundaries:

• java-lib-core evaluation and generation succeeded when the root model had a concrete version attribute;
• omitting the root version produced an empty Maven project version, so fix the source model and regenerate rather than editing the generated POM;
• java-app-console returned No such group file: generator/java-app-console/application.properties.stg from the generation service;
• the generated java-lib-core POM names the nonexistent teaql-data-service-sqlite:1.525-RELEASE; the official released coordinate is io.teaql:teaql-sqlite:1.525-RELEASE;
• an independent diagnostic POM using that official artifact progressed to compilation, where generated entities failed on internalSet and internalGet; teaql-core 1.525-RELEASE and the official main branch expose __internalSet and __internalGet instead. The same entities contain invalid @Override annotations for the unmatched methods.

These are dated observations of the live service and artifact repositories, not permanent support conclusions. Re-run the commands before closing the gaps.

The Java field-change regeneration loop was verified as far as the upstream compile blocker permits. Changing the model to version 1.0.1, adding email, and declaring _audit_mask_fields="email" produced updateEmail, expression, selection, filter, group, order, checker, and audit-mask metadata changes with no runtime-version drift. The regenerated source remains unbuildable for the two template defects above, so Java query and audited-mutation execution are not yet verified.

Rust target findings

With cargo-teaql 2.0.8, the verified sequence is services, evaluate, then the selected dynamic generation target. The older words eval and generate are not aliases for this sequence: an unknown single word is forwarded as a generation scope.

rust-lib-core builds independently. rust-app-console also generates its own lib/ copy, but its manifest currently depends on ../rust-lib-core/lib. Generate both targets into sibling directories before testing the application.

The current generated sample_data.rs uses purpose without comment in two calls. This compiles, but it does not meet the project query-intent contract. Do not edit generated files; report the template defect and keep handwritten queries in comment → purpose → execution order.

The verified model seeds its single domain-root candidate. Attempting to create a second root produced a SQLite primary-key conflict; querying the seeded root and creating an audited child succeeded. Treat root creation according to model semantics rather than assuming every generated entity is a repeatable root.

The Rust regeneration loop is also verified: adding an email scalar and raising the model version to 1.0.1 produced the corresponding entity, expression, selection, filter, group, and order APIs. The evaluator's privacy suggestion was resolved in the source model with _audit_mask_fields="email"; the regenerated entity contained matching audit-mask metadata and passed an offline Cargo test without runtime dependency drift.

Provider Coverage

Current architecture pages describe Java database modules and Rust providers, but a provider name is not proof that every version or feature combination is tested.

Stack	Documented provider/module families	Version/test status
Java	PostgreSQL, MySQL, SQLite, Oracle, DB2, DM8, HANA, SQL Server, DuckDB, Snowflake, portable SQL, memory.	The dated 2026-08-12 engineering matrix executed the first nine SQL engines; Snowflake was not executed. Published version ranges remain pending.
Rust	PostgreSQL, MySQL, SQLite, Meilisearch, memory; Redis is documented as cache integration.	PostgreSQL, MySQL, and SQLite passed the dated generated API/database campaign; other provider, server, and support-lifecycle combinations remain pending.
Go	PostgreSQL, MySQL, SQLite.	All three passed the dated generated API/database campaign.
Python	PostgreSQL, MySQL, SQLite.	All three passed with real async SQL providers.
C# / .NET	PostgreSQL, MySQL, SQLite, SQL Server.	All four passed the dated generated API/database campaign.
TypeScript	PostgreSQL, MySQL, SQLite through explicit Node SQL profiles.	All three passed; the default browser/TFP root profile separately passed a no-database-driver probe.

Evidence Required to Promote a Combination

A row can move from documented to tested only when it records:

• client/generator version;
• generated dependency versions;
• Java or Rust toolchain version;
• host framework and provider/database version;
• exact generation and build/test commands;
• successful date and CI/job or artifact link;
• known limitations.

A combination can be called supported only after a maintainer defines its support and update policy. See Support Lifecycle for the fields that policy must contain.

Remaining Verification Baseline

The first baseline should capture:

1. Close the generated Java artifactId and internalSet/internalGet template defects, then retain a clean Java build.
2. Retain the completed Rust/SQLite evidence in a reproducible CI job.
3. Re-run the already reviewed Java model-change diff after the template fix; Rust is fully verified.
4. Complete one query and one audited mutation on Java; Rust is verified.
5. Retain clean build/test evidence with the release or documentation update.