Rust Data Providers

TeaQL Rust separates generated business APIs from backend execution. The same generated domain API can target PostgreSQL, MySQL, SQLite, Meilisearch, or an in-memory repository depending on which provider is registered in UserContext.

Read Rust Overview first if you need the runtime and generated-crate context. Read Java/Rust Parity & Generator if you need to understand how the same TeaQL model maps to both Java and Rust targets.

Provider Architecture

Generated Q API
  -> generated service crate
  -> RuntimeModule / module()
  -> UserContext
  -> Repository / request policy / graph planning
  -> teaql-data-service traits
  -> Provider
  -> Database, search backend, or memory store

Provider selection is an infrastructure decision. Business query code should stay provider-agnostic.

Current Provider Set

Provider	Backend	Best fit
teaql-provider-postgres	PostgreSQL via deadpool-postgres / tokio-postgres	Production backend services, PostgreSQL-native deployments, reporting and aggregate paths.
teaql-provider-mysql	MySQL via mysql_async	Enterprise MySQL systems and migration paths from MySQL-centric Java stacks.
teaql-provider-sqlite	SQLite via rusqlite	Local-first apps, embedded apps, tests, small services, and simple deployment targets.
teaql-provider-meilisearch	Meilisearch	Search-backed query/mutation experimentation through the data-service boundary.
MemoryRepository	In-memory execution inside teaql-runtime	Unit tests, no-database demos, model validation, and lightweight runtime simulation.

Older docs or examples may mention teaql-provider-sqlx-* or teaql-provider-rusqlite. The current workspace uses the provider crate names above.

PostgreSQL

Use teaql-provider-postgres when you need a server-side PostgreSQL runtime.

Best fit:

• Production backend services
• Complex business systems
• Reporting and aggregation paths
• PostgreSQL deployments with schema bootstrap and id-space generation

Runtime assembly usually follows this shape:

use teaql_provider_postgres::{PgMutationExecutor, PostgresProviderExt};

let mut ctx = teaql_runtime::UserContext::new()
    .with_module(my_domain::module())
    .with_repository_registry(my_domain::repository_registry());

ctx.use_postgres_provider(PgMutationExecutor::new(pool));
ctx.ensure_schema().await?;

MySQL

Use teaql-provider-mysql when the business system standardizes on MySQL or when you are migrating from a MySQL-centric enterprise stack.

Best fit:

• Enterprise MySQL applications
• Business systems moving from handwritten MyBatis-style persistence
• Standard backend services with MySQL operational knowledge

SQLite

Use teaql-provider-sqlite for local-first applications, embedded deployments, tests, and simple operational footprints.

Best fit:

• Local-first business tools
• Embedded or edge deployments
• Developer tests
• Portable demos
• Agent memory on local devices

The current SQLite provider uses rusqlite and supports schema bootstrap, row decoding, transactions, streaming chunks, and ID-space generation.

Meilisearch

Use teaql-provider-meilisearch when experimenting with search-backed execution through the same data-service abstraction.

Best fit:

• Search-oriented query paths
• Projection/index experiments
• Architectures where a generated domain API should route a subset of requests to a search backend

Treat this as provider work, not as a replacement for relational persistence.

MemoryRepository

Use MemoryRepository when you want to exercise generated APIs without a database.

Best fit:

• Unit tests
• No-database demos
• Model validation
• Fast runtime simulation

MemoryRepository is especially useful for agent-generated code tests because it lets reviewers validate generated API usage without provisioning external services.

Choosing a Provider

Need	Provider
Production PostgreSQL backend	teaql-provider-postgres
Enterprise MySQL backend	teaql-provider-mysql
Local or embedded SQLite	teaql-provider-sqlite
Search-backed execution experiment	teaql-provider-meilisearch
Fast tests without storage	MemoryRepository

Common Rules

• Keep generated Q API code provider-agnostic.
• Register providers during runtime assembly.
• Use UserContext::ensure_schema() after registering a provider when the provider supports schema bootstrap.
• Keep provider-specific code in infrastructure setup, not business services.
• Prefer MemoryRepository for no-database tests.
• Use the model's data-service concept to keep backend ownership explicit.

For the shared modeling vocabulary, see KSML data service config.