Rust Data Providers

Evidence boundary: this page is an architecture and selection guide. Only the SQLite 4.1.1 combination has a clean generated build, application start, query, and mutation result in the maintained evidence. Provider names below do not imply a tested version range or support lifetime. See Database Provider Compatibility.

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.

Documented Provider Set

Provider	Backend	Evidence here	Candidate use
teaql-provider-postgres	PostgreSQL	Documented, not version-tested here.	PostgreSQL-backed services after provider verification.
teaql-provider-mysql	MySQL	Documented, not version-tested here.	MySQL-backed services after provider verification.
teaql-provider-sqlite	SQLite via rusqlite	4.1.1 with rusqlite 0.32 tested.	Local/embedded apps, tests, and simple services.
teaql-provider-meilisearch	Meilisearch	Documented, not version-tested here.	Search-backed experiments with explicitly tested semantics.
MemoryRepository	In-memory runtime	Documented, not parity-tested here.	Fast tests that do not claim SQL-provider equivalence.

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

PostgreSQL

Evaluate teaql-provider-postgres when you need a server-side PostgreSQL runtime. Pin a PostgreSQL version and complete the provider verification matrix before adoption; this repository has not yet recorded that execution evidence.

Candidate fit:

• Server-side backend services after production qualification
• Complex business systems
• Reporting and aggregation paths
• PostgreSQL deployments whose schema and ID behavior have been verified

The provider source documents an assembly shape like the following. Treat it as an API orientation example until it is compiled against the pinned provider version:

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

Evaluate teaql-provider-mysql when the business system standardizes on MySQL or when you are migrating from a MySQL-centric enterprise stack. No named MySQL/provider combination has been executed by the maintained Golden Path.

Candidate 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 verified generated SQLite manifest uses rusqlite 0.32. Schema startup, library/application tests, an intent-declared query, and an audited mutation passed for the recorded Golden Path. Broader transaction, streaming, concurrency, and database-version claims require dedicated evidence.

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

This is a discovery table, not a support declaration. Select a candidate here, then qualify the exact versions using the compatibility guide.

Need	Candidate provider
Server-side PostgreSQL backend	teaql-provider-postgres
Enterprise MySQL backend	teaql-provider-mysql
Local or embedded SQLite	teaql-provider-sqlite (verified combination documented above)
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() only when that API and schema behavior have been verified for the pinned provider version.
• 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.