Compatibility Matrix

Status: This page retains July and August 2026 engineering evidence. It is not a live build-status or support-lifetime matrix. For current generator selections and independently released packages, use Latest Versions. For the cross-language capability tracker and open gaps, use the TeaQL Conformance repository.

The evidence below records exact versions and outcomes from earlier campaigns. A later package release does not inherit their green results; conversely, a fixed July defect must not be presented as a current failure. Re-run the owning runtime example locally, then a clean generated consumer, before promoting a new compatibility claim.

Current observed coordinates as of 2026-09-13 are Generator Server 20260911.230811, Java 1.547-RELEASE, Rust 4.3.5, and cargo-teaql 2.0.14. These are version pointers, not an executed combination in the historical tables below.

August database execution evidence

The 2026-08-12 Polyglot Runtime and Database Matrix is newer than the July Golden Path below. It verifies six runtimes and a nine-database Java matrix on recorded commits. It supersedes July blockers for those commits, not every current package or the seventh runtime.

The following tables are retained as historical evidence, including their old wording and version coordinates. Do not follow their pinning advice for a new project; use the current Quick Start and generated dependency manifest.

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 20260906.092036; teaql-java 1.546-RELEASE; teaql-rs 4.3.3; Go v0.1.4; Python/.NET 0.1.2; TypeScript 0.1.9; Swift 0.1.3.
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.

2026-07-13 and 2026-08-13 documented evidence

In the next table, “current” means current at the recorded snapshot date. The labels are preserved as evidence provenance, not present-day status.

Component	Version mentioned by current docs	Evidence level	Support conclusion
Generator Server	20260906.092036	Official TeaQL latest-version endpoint at the snapshot date.	Historical selection; generated output required build verification.
TeaQL Java runtime artifacts	1.546-RELEASE	Version endpoint and remote Maven resolution at the snapshot date.	Historical selection; framework/artifact combinations required clean-build evidence.
TeaQL Rust workspace	4.3.3	Version endpoint and crates.io publication at the snapshot date.	Historical selection; provider/toolchain combinations required clean-build evidence.
cargo-teaql	2.0.13, observed on 2026-08-13.	Client/version checks and maintained command contracts.	Historical client baseline; generated targets required build verification.
TeaQL Maven plugin	1.1.1, 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.1; 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.1 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.

Historical runtime and generator alignment

Generated target	Generator/client	Runtime dependency rule	Verified combination
Java java-lib-core	TeaQL Maven plugin 1.1.1, 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.

2026-07-13 dynamic-target findings

The plugin 1.1.1 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 boundaries at that time:

• 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 generated sample_data.rs in that July run used purpose without comment in two calls. This is a historical generator defect, not a current regression claim. Regenerate and execute a current sample before reopening it.

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.