Skip to main content

Welcome to TeaQL

TeaQL is a generated business API platform for AI-native software. It turns a domain model into type-safe, human-readable APIs that can be used by application developers and AI coding tools without asking them to guess SQL, table relationships, DTO shapes, or runtime policy.

TeaQL has two current centers of gravity:

  • Java-proven productivity for enterprise systems, Spring Boot services, rich domain models, and maintainable business queries.
  • Rust-powered runtime work for MySQL, PostgreSQL, SQLite, embedded SQLite, in-memory tests, edge deployments, and agent memory.

The short version:

Generated Business APIs. Java-proven. Rust-powered. Multi-database ready.

The Five Safeguards of AI Coding​

TeaQL's approach to AI-assisted development does not rely on trusting an agent to infer the right persistence behavior from scattered code. It gives the agent a generated, typed, model-aware API surface and keeps runtime policy behind explicit boundaries.

  1. Constrained API surface. AI callers use generated, model-aware APIs instead of arbitrary storage logic.
  2. Mandatory intent metadata. Queries and mutations should carry business intent through comment, purpose, and/or audit metadata so reviewers and operators can understand why code ran.
  3. Lower generated-code volume. A business operation can be expressed with fewer handwritten integration layers, reducing the amount of code humans must review.
  4. Runtime observability. Execution context, audit metadata, generated query structure, and logs help answer who ran what and why.
  5. Static typing and generated contracts. Java and Rust type systems catch many invalid calls at build time before runtime execution.

TeaQL is not designed to make AI freer. It is designed to make AI work inside explicit model boundaries, typed APIs, auditable operations, and reviewable code.

Choose Your Path​

I want to try TeaQL in 5 minutes​

Start from a starter model, then inspect the generated query APIs.

I want to understand the architecture​

Learn why TeaQL is more than an ORM and how the generated API, runtime context, repositories, and providers fit together.

I want to use TeaQL with AI coding tools​

Use generated business APIs as a stable layer between LLM-generated application code and your database/runtime implementation.

I want to run TeaQL Rust with MySQL, PostgreSQL, or SQLite​

Use the Rust runtime provider model to choose SQLx PostgreSQL, SQLx MySQL, SQLx SQLite, rusqlite SQLite, or MemoryRepository.

Core Ideas​

TeaQL keeps business API design separate from storage execution:

Domain Model
  -> TeaQL Generator
  -> Generated Q API
  -> Runtime Provider
  -> MySQL / PostgreSQL / SQLite / Memory / Edge / Agent

The same domain model can generate APIs that read like business intent:

User userOrderInfo = Q.users()
    .comment("Query users").purpose("Load data").filterWithId(userId)
    .countOrder()
    .facetByOrderStatus("statusWithCount", Q.orderStatus().countOrders())
    .selectOrderList(
        Q.ordersWithId()
            .selectOrderId()
            .selectDate()
            .offset(0, 10)
            .selectLineItemList(Q.lineItemsWithId().selectImageURL().limit(3))
            .countLineItems()
    )
    .execute(context);

One business page can be expressed as one fluent API instead of scattered SQL, XML, DTO mapping, and manual stitching.