Drivers and Backends

Backend Model

Athena resolves backend execution through:

• logical client routing (X-Athena-Client), or
• direct PostgreSQL URI routing for eligible PostgreSQL gateway/SQL-driver paths.

The intended architecture is Athena-top-level dominance:

• Athena owns client identity.
• Athena owns lifecycle and capability checks.
• Drivers own backend execution details.

See Athena Contracts for the canonical rules behind that split.

Supported backend families:

• PostgreSQL via SQLx pools
• Supabase REST or RPC routing
• Scylla/Cassandra CQL driver

Backend Selection Inputs

• X-Athena-Client: primary client and backend selector.
• x-pg-uri: preferred direct PostgreSQL URI routing for eligible routes.
• x-athena-jdbc-url, x-jdbc-url, X-JDBC-URL: compatibility direct PostgreSQL URI headers.
• x-supabase-url and x-supabase-key: direct Supabase routing when using the Supabase path.

For direct PostgreSQL route scope and auth-bypass rules, see Direct PostgreSQL Routing (x-pg-uri).

Operational Notes

• Startup can soft-fail unavailable configured clients while keeping healthy pools active.
• Catalog-backed clients are loaded after config clients and can become available when connectivity is restored.
• Supabase health-aware behavior includes offline tracking and reset support.
• Some deeper catalog and management flows are still more Postgres-shaped than the target Athena contract model; the contracts page documents that drift explicitly.

Related APIs

• POST /query/sql
• POST /gateway/sql
• POST /gateway/rpc
• GET /health/cluster

Reference

See Reference -> Athena API Reference -> query, gateway, rpc, and health sections.

Operation Links

• POST /query/sql
• POST /gateway/sql
• POST /gateway/rpc
• GET /health/cluster