Skip to main content

From ORM Claims to Executed Evidence: Six TeaQL Runtimes and a Nine-Database Java Matrix

· 4 min read
TeaQL Team
TeaQL Team
Core Team

TeaQL now has a dated, executed database baseline across six generated language runtimes: Java, Rust, Go, Python, C#/.NET, and TypeScript.

The headline result is Java's real nine-database matrix:

tests=9 failures=0 errors=0 skipped=0

The databases were PostgreSQL, MySQL, SQLite, Oracle, DB2, DM8 (Dameng), SAP HANA, SQL Server, and DuckDB.

That is meaningful only because these were not adapter-discovery tests. The generated domain APIs compiled and executed schema creation, graph persistence, reconnect queries, optimistic updates, and direct database checks.

Why “the driver exists” is not enough​

An ORM or model-driven runtime can appear to support a database long before an application can trust it. A repository may contain a dialect class, a Maven or npm dependency, and a configuration example while still failing on schema creation, parameter binding, graph writes, or version updates.

For this verification campaign, a database received a green result only after the generated API completed the persistence chain against a real engine:

  1. generate a typed domain library;
  2. compile it with the corresponding runtime;
  3. create or verify schema;
  4. create a parent and child through generated APIs;
  5. perform an audited cascade save;
  6. reconnect and query through intent-declared requests;
  7. verify the relationship;
  8. update and verify the optimistic version;
  9. query the database directly to confirm stored rows and version.

This is the difference between source presence and executed evidence.

The database matrix​

RuntimeVerified databases
JavaPostgreSQL, MySQL, SQLite, Oracle, DB2, DM8, SAP HANA, SQL Server, DuckDB
RustPostgreSQL, MySQL, SQLite
GoPostgreSQL, MySQL, SQLite
PythonPostgreSQL, MySQL, SQLite
C# / .NETPostgreSQL, MySQL, SQLite, SQL Server
TypeScriptPostgreSQL, MySQL, SQLite

Java currently has the broadest enterprise database coverage. SQL Server is also verified for .NET, while it remains intentionally outside the Rust scope.

Snowflake is not included in the verified set. TeaQL has a Java integration path, but we did not find an official Snowflake database server image suitable for local execution. We chose to report that boundary instead of turning configuration presence into a support claim.

DM8 was the ninth Java database​

DM8 introduced a useful operational lesson. An existing test container had an expired local license, so it could not be treated as valid database evidence. The test used the already available image with a fresh, dedicated data volume, a loopback-only port, and isolated credentials.

The generated DM8 path then completed the same parent-child persistence and version checks as the other Java databases. The shared container and its data directory were not modified.

That distinction matters: evidence should describe the environment that actually passed, including isolation and known limitations.

Six languages, one generated domain contract​

Database breadth is only one half of the result. The same model-driven API shape is now executable across six language ecosystems.

The snapshot retained these runtime results:

  • Rust: generated SQL chains passed for PostgreSQL, MySQL, and SQLite; runtime branch coverage reached 95.5%;
  • Go: the three-database generated matrix passed, including SelectQuery.WithComment compatibility; statement coverage reached 94.9%;
  • Python: 73 runtime tests passed, and the generated database matrix used real async PostgreSQL, MySQL, and SQLite providers rather than the earlier JSON/fake runtime;
  • .NET: 124 runtime tests passed, with generated integration for PostgreSQL, MySQL, SQLite, and SQL Server;
  • TypeScript: six runtime tests and a four-test generated SQL matrix passed for PostgreSQL, MySQL, and SQLite.

These results make TeaQL more than a conventional object-to-table mapper. The domain model also governs typed queries, audited graph mutations, optimistic concurrency, and generated APIs across language boundaries.

TypeScript remains browser-safe​

Adding Node database providers must not make every TypeScript consumer install server-only drivers.

TeaQL TypeScript therefore exposes PostgreSQL, MySQL, and SQLite through explicit SQL subpaths. A separate clean-install probe verified that the default browser/TFP root import:

  • installs no database driver;
  • loads zero database driver modules;
  • imports no SQL runtime from the root entry.

This keeps TypeScript usable as a full-stack runtime without turning the browser profile into a disguised Node bundle.

What the result does and does not claim​

The 2026-08-12 matrix is development-branch engineering evidence. Some commits may not yet be present in the latest published packages. A successful row also does not define a supported database-version range, load limit, or maintenance SLA.

It does establish something concrete: for the recorded commits and test environment, the generated API and runtime crossed the full persistence boundary and returned verified database state.

The maintained matrix and preserved report excerpts are available in:

Future runs will append dated evidence rather than silently broadening the meaning of “supported.”