Docker with PostgreSQL

PostgreSQL is not yet implemented

club does not currently support PostgreSQL as a metadata store. The DB_BACKEND=postgres code path exists only as a placeholder: if you set it, the server throws UnimplementedError('PostgreSQL backend not yet implemented.') on startup and refuses to boot.

SQLite is the only supported metadata store today. Do not use DB_BACKEND=postgres, the POSTGRES_URL variable, or the docker-compose.postgres.yml override file for a production deployment.

Current state

club ships with a single metadata store implementation: SQLite (via drift, using raw SQL). It is the default and the only working backend.

The repository contains a docker/docker-compose.postgres.yml override and a DB_BACKEND environment variable, but the PostgreSQL MetadataStore implementation has not been written. Until it lands, DB_BACKEND has only one valid value: sqlite (the default).

What SQLite handles

SQLite is not a limitation for most teams. It handles thousands of packages and many concurrent readers without issue. Writes (publishing) are serialized, which is rarely a bottleneck for a private registry.

For metadata storage, stick with the default:

# .env — this is the default; you don't need to set it explicitly
DB_BACKEND=sqlite
SQLITE_PATH=/data/db/club.db

The SQLite database lives on the /data volume at /data/db/club.db. See Docker deployment for the full deployment guide and backup instructions.

Scaling storage instead

If your concern is storage capacity or running multiple replicas, the metadata store is not the part you need to change. What you can offload today is blob storage: package tarballs and assets can be moved to S3-compatible object storage or Google Cloud Storage. See Docker with S3 storage.