Summary

GizmoSQL supports both DuckDB and SQLite through the DATABASE_BACKEND container setting, but pytest-databases currently exposes only the backend-ambiguous gizmosql_service fixture. Consumers that need to exercise both backends must reimplement DockerService.run(), readiness checks, credentials, TLS settings, xdist naming, and teardown locally.

Proposed API

• Add gizmosql_duckdb_service, explicitly configured with DATABASE_BACKEND=duckdb.
• Add gizmosql_sqlite_service, explicitly configured with DATABASE_BACKEND=sqlite.
• Retain gizmosql_service as a backward-compatible alias or wrapper for gizmosql_duckdb_service.
• Reuse the existing image, username, password, and server-isolation fixtures rather than duplicating lifecycle code.
• Give each backend a distinct container name so both fixtures can be requested in one test session.

The backend-specific services should work with the clientless readiness approach in #141; no backend-specific connection fixture is required.

Motivation

The GizmoSQLService documentation describes DuckDB and SQLite backends, while the public fixture surface can provision only the implicit default. SQLSpec needs both backends for its Flight SQL adapter integration matrix and currently has to shadow the native gizmosql_service and hand-roll a second SQLite service. Backend-specific upstream fixtures would let consumers rely entirely on pytest-databases for container lifecycle, as intended.

Acceptance criteria

• Both backend fixtures can run independently and in the same pytest session.
• Each fixture sets DATABASE_BACKEND explicitly and uses a backend-specific container name.
• pytest -n 2 remains isolated with xdist_gizmosql_isolation_level=server.
• Existing users of gizmosql_service retain DuckDB-default behavior.
• Documentation lists the new fixtures and identifies the compatibility alias.

Version context

Observed in pytest-databases 0.19.0 and still present in the open #141 implementation.