database-compose.yml

# Shared configuration for every Druid process. Druid is configured entirely through
# `druid_*` environment variables (the image's entrypoint translates them into
# runtime.properties), so one anchor keeps the five processes provably identical - a cluster
# whose processes disagree about ZooKeeper or the metadata store fails in confusing ways.
x-druid-env: &druid-env
  # Sizes every process for a laptop. Without it each one claims cluster-scale heap and
  # direct memory, and the five together will not fit.
  DRUID_SINGLE_NODE_CONF: micro-quickstart
  # druid-multi-stage-query is included on purpose: it is what makes `INSERT INTO ... SELECT`
  # (MSQ) available on /druid/v2/sql/task. The provider does not use that endpoint - the point
  # is that the live pass can prove the *synchronous* endpoint rejects INSERT even when the
  # engine is fully capable of it, which is the honest reason supportsCreateTable is false.
  druid_extensions_loadList: '["druid-histogram", "druid-datasketches", "druid-lookups-cached-global", "postgresql-metadata-storage", "druid-multi-stage-query"]'
  druid_zk_service_host: druid-zookeeper
  druid_metadata_storage_host: ""
  druid_metadata_storage_type: postgresql
  druid_metadata_storage_connector_connectURI: jdbc:postgresql://druid-metadata:5432/druid
  druid_metadata_storage_connector_user: druid
  druid_metadata_storage_connector_password: druid
  # Deep storage on a shared local volume. Real deployments use S3/HDFS; local is what makes
  # this a single-machine fixture, and the historical and middlemanager must see the same files.
  druid_storage_type: local
  druid_storage_storageDirectory: /opt/shared/segments
  druid_indexer_logs_type: file
  druid_indexer_logs_directory: /opt/shared/indexing-logs
  druid_indexer_runner_javaOptsArray: '["-server", "-Xmx1g", "-Xms1g", "-XX:MaxDirectMemorySize=1g", "-Duser.timezone=UTC", "-Dfile.encoding=UTF-8", "-Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager"]'
  druid_indexer_fork_property_druid_processing_buffer_sizeBytes: 100MiB
  druid_processing_numThreads: "2"
  druid_processing_numMergeBuffers: "2"
  # Lets the Router at 8888 proxy Coordinator and Overlord APIs, so the whole cluster is
  # reachable through the one port the provider targets.
  druid_router_managementProxy_enabled: "true"
  # info, not the upstream compose's debug: the debug logger emits one line per internal
  # request and buries the errors a live pass is looking for.
  druid_emitter_logging_logLevel: info

services:
  postgres:
    image: postgres:18
    container_name: libredb-postgres
    restart: unless-stopped
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
      POSTGRES_DB: postgres
    ports:
      # Loopback only: postgres/postgres is committed in this file, so keep this
      # database off the host's LAN address.
      - "127.0.0.1:5432:5432"
    volumes:
      # The seed this file's postgres is for. Without it the service came up with an
      # empty `postgres` database and no `libredb_dev` at all, so the object-tree
      # fixture in 02-sample-data.sql (#710, #789) was never applied and an acceptance
      # run measured an absence we had created. The scripts run in alphabetical order
      # and ONLY on a fresh data directory, so an existing container has to be
      # recreated before they take effect.
      - ./docker/postgres-init:/docker-entrypoint-initdb.d:ro
  mongodb:
    image: mongo:latest
    container_name: libredb-mongodb
    restart: unless-stopped
    environment:
      MONGO_INITDB_ROOT_USERNAME: admin
      MONGO_INITDB_ROOT_PASSWORD: admin
    ports:
      - "27017:27017"
    volumes:
      # The object-browser fixture (#789). The image runs every .js in this directory
      # through mongosh once, on a FRESH data directory only, so an already-initialized
      # container has to be recreated before an edit to that file takes effect. Connect
      # against the `app` database it creates; `configstore` is there so the reserved
      # database names stay excluded by exact name rather than by prefix.
      - ./docker/mongodb-init:/docker-entrypoint-initdb.d:ro
  mysql:
    image: mysql:latest
    container_name: libredb-mysql
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: root
      MYSQL_DATABASE: mysql
    ports:
      - "3306:3306"
    volumes:
      # The object-browser fixture (#789). The image runs it once, on a FRESH data
      # directory only, so an already-initialized container has to be recreated before an
      # edit to that file takes effect. Connect against the `app` database it creates.
      - ./docker/mysql-init:/docker-entrypoint-initdb.d:ro
  mssql:
    # Use 2022-latest to avoid SQL Server 2025 NUMA/processor topology assert in containers.
    # Limit CPUs to avoid: ASSERT (result * DrtlGetProcessorCoreCount() == DrtlGetProcessorCount())
    image: mcr.microsoft.com/mssql/server:2022-latest
    container_name: libredb-mssql
    restart: unless-stopped
    # No init-script mount, and that is the image rather than an omission: this one has no
    # init-script directory at all. `docker/mssql-init/` holds two scripts to apply by hand,
    # each carrying its own `docker cp` + `sqlcmd` line - the object-browser fixture, and the
    # least-privilege principal the agent read-only execution profile requires.
    environment:
      ACCEPT_EULA: "Y"
      MSSQL_SA_PASSWORD: Password123!
      MSSQL_DATABASE: mssql
    ports:
      - "1433:1433"
    deploy:
      resources:
        limits:
          cpus: "4"
          memory: 4G
  oracle:
    image: gvenzl/oracle-xe
    container_name: libredb-oracle
    restart: unless-stopped
    environment:
      # Inert against this image and left alone rather than removed, because it records
      # what somebody expected. ORACLE_PDB is the Oracle-published image's variable;
      # gvenzl/oracle-xe reads ORACLE_DATABASE, and setting that one creates a SECOND
      # pluggable database and adds minutes to the first start. Measured: the service name
      # to connect to is XEPDB1.
      ORACLE_PDB: ORCLPDB1
      ORACLE_PASSWORD: Password123!
    ports:
      - "1521:1521"
    volumes:
      # The object-browser fixture (#789, #765): two owners, one object of every declared
      # kind, and a package whose body deliberately does not compile. SQL*Plus runs these
      # once and ONLY on a fresh data directory, so an existing container has to be
      # recreated before an edit takes effect. Connect as APP / Password123! on XEPDB1.
      - ./docker/oracle-init:/container-entrypoint-initdb.d:ro
  db2:
    # IBM Db2 Community Edition, the engine the Db2 provider (#786) was measured on.
    image: icr.io/db2_community/db2:12.1.0.0
    container_name: libredb-db2
    restart: unless-stopped
    # Unprivileged: IBM's run instructions pass --privileged, but the instance only needs
    # these two capabilities for its shared memory. Measured on a container started this
    # way: Privileged=false, CapAdd=[CAP_IPC_LOCK CAP_IPC_OWNER], and the database starts.
    cap_add:
      - IPC_LOCK
      - IPC_OWNER
    environment:
      LICENSE: accept
      DB2INSTANCE: db2inst1
      DB2INST1_PASSWORD: Password123
      DBNAME: testdb
      ARCHIVE_LOGS: "false"
      AUTOCONFIG: "false"
      SAMPLEDB: "false"
    ports:
      - "50000:50000"
    volumes:
      # The object-browser fixture: schemas APP and REPORTING, one object of every kind the
      # provider lists, and the tables the maintenance and value tests use. The image
      # executes EVERY file in /var/custom on every start, so only the script goes there and
      # the .sql it feeds to the CLP is mounted elsewhere. The script loads the fixture once
      # and skips it when APP.ORDERS exists, so an edit takes effect on a fresh volume only.
      # Connect as db2inst1 / Password123 to TESTDB.
      - ./docker/db2-init/01-object-fixture.sh:/var/custom/01-object-fixture.sh:ro
      - ./docker/db2-init/01-object-fixture.sql:/var/custom-fixture/01-object-fixture.sql:ro
    healthcheck:
      # The first start creates the instance and the database, which takes minutes.
      test: ["CMD-SHELL", "su - db2inst1 -c 'db2gcf -s' | grep -q Available"]
      interval: 15s
      timeout: 10s
      retries: 40
      start_period: 120s
  couchbase:
    # The image ships an uninitialized node: the cluster, the credentials below,
    # the bucket and its primary index are all applied by the couchbase-init
    # sidecar that follows.
    image: couchbase:community-8.0.2
    container_name: libredb-couchbase
    restart: unless-stopped
    environment:
      COUCHBASE_USER: Administrator
      COUCHBASE_PASSWORD: password123
    ports:
      # 8091 management REST, 8093 query service (SQL++). Those are the only two
      # the provider needs: it speaks HTTP, never the binary KV protocol (11210).
      - "8091:8091"
      - "8093:8093"
    ulimits:
      # Couchbase warns at every start below this and degrades under load.
      nofile:
        soft: 200000
        hard: 200000
    healthcheck:
      # Authenticated on purpose: /pools answers anonymously only until the
      # cluster is initialized, and returns 401 for every later start, which
      # would leave an initialized node permanently "unhealthy". With
      # credentials it answers 200 in both states.
      test:
        - CMD-SHELL
        - 'curl -sf -o /dev/null -u "$$COUCHBASE_USER:$$COUCHBASE_PASSWORD" http://localhost:8091/pools'
      interval: 5s
      timeout: 5s
      retries: 40
  couchbase-init:
    # One-shot sidecar. A fresh node has no cluster, no bucket and no index, and
    # SQL++ rejects a SELECT against an un-indexed keyspace with error 4000, so
    # without this the service would come up unusable.
    image: couchbase:community-8.0.2
    container_name: libredb-couchbase-init
    restart: "no"
    depends_on:
      couchbase:
        condition: service_healthy
    environment:
      COUCHBASE_HOST: couchbase
      COUCHBASE_USER: Administrator
      COUCHBASE_PASSWORD: password123
      COUCHBASE_BUCKET: travel
    volumes:
      # The object-browser fixture (#789). Couchbase has no
      # /docker-entrypoint-initdb.d, so the sidecar sources it after the cluster,
      # the bucket and the bucket-level primary index exist. The script is
      # re-runnable, so `docker compose up couchbase-init` re-applies an edit
      # without recreating the data node.
      - ./docker/couchbase-init:/fixture:ro
    entrypoint: ["/bin/bash", "-c"]
    command:
      # $$ escapes compose interpolation: these expand in the container's shell.
      - |
        set -eu
        couchbase-cli cluster-init -c "$$COUCHBASE_HOST" \
          --cluster-username "$$COUCHBASE_USER" --cluster-password "$$COUCHBASE_PASSWORD" \
          --cluster-name libredb --services data,index,query \
          --cluster-ramsize 1024 --cluster-index-ramsize 512 --index-storage-setting default \
          || echo "cluster already initialized - existing settings left untouched"
        # Community Edition rejects Magma, which bucket-create defaults to, and a
        # single node cannot honour a replica.
        couchbase-cli bucket-create -c "$$COUCHBASE_HOST" \
          -u "$$COUCHBASE_USER" -p "$$COUCHBASE_PASSWORD" \
          --bucket "$$COUCHBASE_BUCKET" --bucket-type couchbase --storage-backend couchstore \
          --bucket-ramsize 256 --bucket-replica 0 --wait \
          || echo "bucket already exists - existing data left untouched"
        # The query service accepts statements a few seconds after the node is
        # initialized, so the index creation is retried rather than assumed.
        for _ in $$(seq 1 30); do
          if curl -sf -o /dev/null -u "$$COUCHBASE_USER:$$COUCHBASE_PASSWORD" \
            "http://$$COUCHBASE_HOST:8093/query/service" \
            --data-urlencode "statement=CREATE PRIMARY INDEX IF NOT EXISTS ON \`$$COUCHBASE_BUCKET\`"; then
            echo "couchbase ready: bucket $$COUCHBASE_BUCKET has a primary index"
            # The object-browser fixture (#789): the scope, the collections, the
            # two same-named indexes, the two same-named scope functions, the
            # global function and the legacy map-reduce view. Every claim the
            # provider doc makes about this engine is re-measurable against it.
            exec bash /fixture/01-object-fixture.sh
          fi
          sleep 2
        done
        echo "couchbase-init: the query service never accepted CREATE PRIMARY INDEX" >&2
        exit 1
  clickhouse:
    # Pinned to the exact build the provider was live-verified against, so the status
    # codes, header names and mid-stream-failure trailer recorded in
    # docs/providers/clickhouse.md stay reproducible for the next person.
    image: clickhouse/clickhouse-server:26.7.1.1315
    container_name: libredb-clickhouse
    restart: unless-stopped
    environment:
      CLICKHOUSE_USER: libredb
      CLICKHOUSE_PASSWORD: password123
      CLICKHOUSE_DB: demo
      # Lets the live pass GRANT/REVOKE a second, restricted user (needed to reproduce the
      # ACCESS_DENIED-arrives-as-500 finding, spec section 2.5) without hand-editing users.xml.
      CLICKHOUSE_DEFAULT_ACCESS_MANAGEMENT: 1
    ports:
      # 8123 is HTTP, the only protocol the provider speaks. 9000 (native TCP) is deliberately
      # NOT exposed: there is no native-protocol transport in this codebase to connect with it.
      - "8123:8123"
    volumes:
      # The object-browser fixture (#789). The image feeds these to clickhouse-client once,
      # on a FRESH data directory only, so an already-initialized container has to be
      # recreated before an edit to that file takes effect. Connect against the `demo`
      # database CLICKHOUSE_DB creates.
      - ./docker/clickhouse-init:/docker-entrypoint-initdb.d:ro
      # A CONFIG-FILE dictionary, which SQL cannot create. Measured: such a dictionary has
      # no system.tables row at all and lives only in system.dictionaries with an empty
      # database, so it is the only object that exercises the provider's dictionary union.
      # The default config's <dictionaries_config>*_dictionary.*ml</dictionaries_config> glob
      # is what picks this file up, so the `_dictionary.xml` suffix and this exact directory
      # are both load-bearing.
      - ./docker/clickhouse-config/regions_dictionary.xml:/etc/clickhouse-server/regions_dictionary.xml:ro
    ulimits:
      # ClickHouse warns at every start below this and degrades under load, same class of
      # issue as the couchbase nofile setting above.
      nofile:
        soft: 262144
        hard: 262144
    healthcheck:
      # /ping needs no auth and returns "Ok." once the server can accept queries. The image has
      # no curl (unlike couchbase's), so this uses wget, which it does ship.
      test: ["CMD", "wget", "--spider", "-q", "http://localhost:8123/ping"]
      interval: 5s
      timeout: 5s
      retries: 40
    # No seed sidecar: CLICKHOUSE_DB above creates `demo` on first boot, the init mount seeds
    # it, and unlike Couchbase there is no index prerequisite - a SELECT against a freshly
    # created table works immediately. Do not add one.

  # ---------------------------------------------------------------------------------------
  # Apache Druid. Unlike every other service here, Druid is a distributed system and has no
  # single-container mode: five Druid processes plus ZooKeeper plus a metadata database is
  # the minimum that can answer a SQL query. That is why all seven carry `profiles: [druid]`
  # - a bare `docker compose -f database-compose.yml up -d` would otherwise grow from 7
  # containers to 14 and from roughly 6 GB of RAM to 12. Start it explicitly:
  #
  #   docker compose -f database-compose.yml --profile druid up -d
  #
  # The provider only ever talks to the Router (8888) or the Broker (8082); the other five
  # processes are cluster internals and deliberately publish no host port. 8091, the
  # MiddleManager's usual port, is already taken by couchbase above - another reason not to.
  # ---------------------------------------------------------------------------------------
  druid-metadata:
    # Druid's metadata store (segment table, task history, supervisors, config). Distinct
    # from the `postgres` service above on purpose: sharing it would put Druid's ~20 internal
    # tables into the demo database the studio's own postgres connection browses.
    image: postgres:17.6
    container_name: libredb-druid-metadata
    profiles: ["druid"]
    restart: unless-stopped
    environment:
      POSTGRES_USER: druid
      POSTGRES_PASSWORD: druid
      POSTGRES_DB: druid
    # No published port: only the Druid Coordinator/Overlord reads it, over the compose
    # network. Publishing it would collide with the `postgres` service on 5432.
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U druid -d druid"]
      interval: 5s
      timeout: 5s
      retries: 30
  druid-zookeeper:
    # Druid's cluster coordination: process discovery, segment load queues, task assignment.
    image: zookeeper:3.9.3
    container_name: libredb-druid-zookeeper
    profiles: ["druid"]
    restart: unless-stopped
    environment:
      ZOO_MY_ID: "1"
      # zkServer.sh's own status check uses the `srvr` four-letter word, which 3.9 refuses
      # unless it is whitelisted.
      ZOO_4LW_COMMANDS_WHITELIST: "srvr,ruok,conf"
    healthcheck:
      test: ["CMD-SHELL", "echo ruok | nc -w 2 localhost 2181 | grep -q imok"]
      interval: 5s
      timeout: 5s
      retries: 30
  druid-coordinator:
    # Coordinator + Overlord in one process (the image's coordinator config sets
    # druid.coordinator.asOverlord.enabled), so segment balancing and task management both
    # live here. This is what accepts an ingestion task, which is how a datasource is
    # created at all - Druid has no CREATE TABLE.
    image: apache/druid:37.0.0
    container_name: libredb-druid-coordinator
    profiles: ["druid"]
    restart: unless-stopped
    command: ["coordinator"]
    environment: *druid-env
    volumes:
      - druid_shared:/opt/shared
      - druid_coordinator_var:/opt/druid/var
    depends_on:
      druid-metadata:
        condition: service_healthy
      druid-zookeeper:
        condition: service_healthy
    healthcheck:
      test: ["CMD", "wget", "--spider", "-q", "http://localhost:8081/status/health"]
      interval: 10s
      timeout: 5s
      retries: 40
  druid-historical:
    # Serves published segments. Without it a datasource exists in the metadata store but
    # returns no rows, which is the "datasource with no segments" case the provider has to
    # render honestly.
    image: apache/druid:37.0.0
    container_name: libredb-druid-historical
    profiles: ["druid"]
    restart: unless-stopped
    command: ["historical"]
    environment: *druid-env
    volumes:
      - druid_shared:/opt/shared
      - druid_historical_var:/opt/druid/var
    depends_on:
      druid-coordinator:
        condition: service_started
      druid-zookeeper:
        condition: service_healthy
  druid-middlemanager:
    # Runs ingestion tasks as forked peon processes. Needed for the live pass to load data.
    image: apache/druid:37.0.0
    container_name: libredb-druid-middlemanager
    profiles: ["druid"]
    restart: unless-stopped
    command: ["middleManager"]
    environment: *druid-env
    volumes:
      - druid_shared:/opt/shared
      - druid_middlemanager_var:/opt/druid/var
    depends_on:
      druid-coordinator:
        condition: service_started
      druid-zookeeper:
        condition: service_healthy
  druid-broker:
    # Plans and merges queries. POST /druid/v2/sql here is the same API the Router proxies,
    # so the provider works against 8082 directly too - published so that can be proven
    # rather than assumed.
    image: apache/druid:37.0.0
    container_name: libredb-druid-broker
    profiles: ["druid"]
    restart: unless-stopped
    command: ["broker"]
    environment: *druid-env
    volumes:
      - druid_broker_var:/opt/druid/var
    ports:
      - "8082:8082"
    depends_on:
      druid-coordinator:
        condition: service_started
      druid-zookeeper:
        condition: service_healthy
    healthcheck:
      test: ["CMD", "wget", "--spider", "-q", "http://localhost:8082/status/health"]
      interval: 10s
      timeout: 5s
      retries: 40
  druid-router:
    # The provider's default target. It fronts the SQL API, the web console and - because
    # druid_router_managementProxy_enabled is set - the Coordinator and Overlord APIs, so a
    # single port is enough for both querying and loading data.
    image: apache/druid:37.0.0
    container_name: libredb-druid-router
    profiles: ["druid"]
    restart: unless-stopped
    command: ["router"]
    environment: *druid-env
    volumes:
      - druid_router_var:/opt/druid/var
      # The object-surface fixture (#789). Druid's image has no init-script directory
      # and Druid has no CREATE statement at all, so the fixture is a lookup map plus
      # three ingestion task specs and a script that applies them:
      #
      #   docker exec libredb-druid-router bash /opt/druid-init/apply.sh
      #
      # Mounted on the Router because the Router fronts the SQL endpoint AND, through
      # the management proxy, the Coordinator and Overlord APIs the fixture needs.
      - ./docker/druid-init:/opt/druid-init:ro
    ports:
      - "8888:8888"
    depends_on:
      druid-broker:
        condition: service_started
      druid-coordinator:
        condition: service_started
    healthcheck:
      test: ["CMD", "wget", "--spider", "-q", "http://localhost:8888/status/health"]
      interval: 10s
      timeout: 5s
      retries: 40

  # Redis, as a service rather than a hand-started container. Its absence was the
  # one hole in the shipped set (#424): `redis` had no compose entry, so its own
  # gate-4 probe could not be reproduced on a clean machine.
  redis:
    image: redis:latest
    container_name: libredb-redis
    restart: unless-stopped
    ports:
      - "6379:6379"
    # The object-browser fixture (#789) is NOT mounted here on purpose: this image has no
    # init-script directory and no entrypoint hook of any kind, so there is nowhere to mount
    # it that would run it. Apply it by hand, in one command, once the service is up:
    #   docker exec -i libredb-redis redis-cli --no-raw < docker/redis-init/01-object-fixture.redis
    # redis-cli reading stdin uses ONE connection for the whole file, which is what makes the
    # `SELECT 3` in the middle of it land in database 3. See docs/providers/redis.md 11.5.
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 5s
      timeout: 3s
      retries: 10

  # ---------------------------------------------------------------------------------------
  # Search engines (issue #424, Phase 1). Two type-ids, one provider module, so BOTH have to
  # be runnable at once: every claim the provider records is a claim about which of the two
  # answered differently, and that can only be re-measured side by side.
  #
  # This is the exact configuration the Phase 1 probes ran against (read back with
  # `docker inspect`): single-node discovery, security off, and a 512 MB heap each - about
  # 1.2 GB of RSS for the pair. No `profiles:` on purpose, unlike the druid block: these are
  # SHIPPED providers, so a plain `docker compose up` has to be able to reproduce their
  # integration pass, the same rule clickhouse and couchbase follow above.
  #
  # Security is DISABLED on both, which is what makes the fixtures reproducible - and it is
  # also the limit of what they can prove: a bogus `Basic` header is IGNORED here (HTTP 200
  # on both, measured), so no 401/403 body could ever be captured from these containers. The
  # transport decides `auth` on the HTTP status alone for exactly that reason.
  # ---------------------------------------------------------------------------------------
  elasticsearch:
    # Pinned to the exact build the provider was live-verified against, the same rule the
    # clickhouse service follows: the status codes, fault names and paging behaviour recorded
    # in docs/providers/elasticsearch.md are version-specific claims.
    image: docker.elastic.co/elasticsearch/elasticsearch:9.1.4
    container_name: libredb-elasticsearch
    restart: unless-stopped
    environment:
      # One node forms its own cluster; without it the node waits for a seed host it will
      # never find and the SQL endpoint never comes up.
      discovery.type: single-node
      # Off, so the endpoint is plain HTTP with no bootstrap password or enrolment token. The
      # SQL API itself needs no licence beyond basic - that is what makes SQL, and not ES|QL,
      # the query language both products can share.
      xpack.security.enabled: "false"
      # Sized for a laptop. The image otherwise claims a heap from the host's total memory.
      ES_JAVA_OPTS: "-Xms512m -Xmx512m"
    volumes:
      # The object-surface fixture (#789). Neither image has an init-script directory
      # and neither product has DDL - an index, an alias, an ingest pipeline, an index
      # template and a data stream are all created over REST - so the fixture is a
      # script, mounted read-only and run by hand or by `docker exec`. The exact
      # commands are in docs/providers/elasticsearch.md.
      - ./docker/search-init:/opt/search-init:ro
    ports:
      # 9200 is the HTTP API, the only protocol this provider speaks. 9300 (transport) is
      # deliberately not published: there is no transport-protocol client in this codebase.
      - "9200:9200"
    healthcheck:
      # `_cluster/health` answers before any index exists, so it does not need seed data. A
      # single-node cluster with a replica requested is YELLOW and never green, so waiting
      # for green here would hang forever. The image ships curl.
      test: ["CMD", "curl", "-sf", "http://localhost:9200/_cluster/health?wait_for_status=yellow&timeout=3s"]
      interval: 5s
      timeout: 5s
      retries: 40

  opensearch:
    # Pinned for the same reason, and here the reason is sharper: the SQL PLUGIN's fault
    # names are Java class names that its own releases rename, and `latest` resolved to 3.8.0
    # when the provider was measured (`GET /` reported distribution `opensearch`, number
    # 3.8.0, build_date 2026-08-01).
    image: opensearchproject/opensearch:3.8.0
    container_name: libredb-opensearch
    restart: unless-stopped
    environment:
      discovery.type: single-node
      # The fork's own switch, and NOT the same key as Elasticsearch's: the security plugin
      # is installed rather than a licensed feature, so it is disabled by name. Without this
      # the node serves HTTPS with a self-signed certificate and a default admin password.
      DISABLE_SECURITY_PLUGIN: "true"
      OPENSEARCH_JAVA_OPTS: "-Xms512m -Xmx512m"
    volumes:
      # The same fixture script, unchanged: every endpoint it calls answered identically
      # on both products (#789). See docs/providers/opensearch.md for the commands.
      - ./docker/search-init:/opt/search-init:ro
    ports:
      # 9201 on the host because both products ship on 9200 in the container and the
      # elasticsearch service above already publishes it. The provider's default port stays
      # 9200 - this is a collision on THIS machine, not a fact about the product.
      - "9201:9200"
    healthcheck:
      test: ["CMD", "curl", "-sf", "http://localhost:9200/_cluster/health?wait_for_status=yellow&timeout=3s"]
      interval: 5s
      timeout: 5s
      retries: 40
    # No seed sidecar, and one thing to expect instead: a stock node ships its own indices.
    # Measured on an empty 3.8.0 cluster, `.plugins-ml-config` and `top_queries-<date>-<n>`
    # are already there, so two thirds of the index listing is the engine's bookkeeping. The
    # provider hides both; the second one carries no leading dot, so the dot convention alone
    # does not catch it.

  # ---------------------------------------------------------------------------------------
  # libSQL server (issue #424, Phase 5). SQLite over a network: one container is the whole
  # server, and it is the SELF-HOSTED half of the `libsql` type-id. The other half is Turso
  # Cloud, which cannot be a compose service - it is an account - so the doc records what was
  # measured there and this service is what anyone can repeat.
  # ---------------------------------------------------------------------------------------
  libsql:
    # Pinned to the exact build the provider was live-verified against, the same rule the
    # trino and clickhouse services follow: the refusal wording recorded in
    # docs/providers/libsql.md ("unsupported statement: VACUUM") is a claim about sqld
    # 0.24.33, and Turso Cloud words the identical refusal differently.
    #
    # The tag is needed even though `:latest` reports the same 0.24.33: measured 2026-08-27,
    # `:latest` is a ROLLING REBUILD of that version - it answers `/version` with
    # `sqld 0.24.33 (f8fb14f3 2026-08-11)` where `v0.24.33` answers
    # `sqld 0.24.33 (40a151bd 2025-12-19)`, two different digests under one version number.
    # So `:latest` is not reproducible even while the number it prints looks pinned.
    image: ghcr.io/tursodatabase/libsql-server:v0.24.33
    container_name: libredb-libsql
    restart: unless-stopped
    environment:
      # A single primary with no replica. Without it sqld starts in a mode that expects a
      # primary to follow, and the first write fails rather than the server failing to start.
      SQLD_NODE: primary
    ports:
      # 8080 carries the Hrana HTTP API AND the version route - one port, and there is no
      # second protocol port to publish. Mapped to 18080 so it cannot collide with the trino
      # service above, which owns 8080 on the host.
      - "18080:8080"
    healthcheck:
      # sqld's own route, and it answers WITHOUT a token - which is exactly why it is a
      # health check and not a connection test: the provider proves the credential with
      # `SELECT 1` instead (see connect() in the provider).
      #
      # Spoken through bash's /dev/tcp rather than curl, because the image ships NEITHER
      # curl NOR wget (checked before writing this, the same way the trino service's
      # comment says to: `command -v wget || command -v curl` answers nothing, while
      # /bin/bash and /bin/sqld are both there). A `CMD curl` here would have marked the
      # service permanently unhealthy while the server answered every request.
      # `CMD bash -c`, never `CMD-SHELL`: CMD-SHELL runs /bin/sh, which is dash here, and
      # dash has no /dev/tcp - measured, the check failed with "cannot create
      # /dev/tcp/localhost/8080: Directory nonexistent" while the server was answering.
      test:
        - CMD
        - bash
        - -c
        - exec 3<>/dev/tcp/localhost/8080 && printf 'GET /health HTTP/1.0\r\n\r\n' >&3 && head -1 <&3 | grep -q 200
      interval: 10s
      timeout: 5s
      retries: 10

  # ---------------------------------------------------------------------------------------
  # DuckDB (issue #424) has NO service here, and that is not an oversight.
  #
  # It is an EMBEDDED engine: the driver is a native N-API addon this app loads into its own
  # process, and the whole connection is a file path (or `:memory:`). There is no server to
  # start and nothing listening on a port, so a container would have nothing to run - the same
  # reason `sqlite` and the embedded `libredb` have no service either. The file also admits
  # exactly ONE operating-system process, measured refused even in read-only mode, so a
  # sidecar holding it open would lock the app out rather than help it.
  #
  # To repeat the live pass, build a local file instead of starting a service - see
  # docs/providers/duckdb.md.
  # ---------------------------------------------------------------------------------------

  # ---------------------------------------------------------------------------------------
  # Trino (issue #424, Phase 2). One container is the whole cluster: the coordinator
  # runs the worker in-process by default, which is enough to answer every statement the
  # provider sends. Nothing else is needed to exercise it.
  # ---------------------------------------------------------------------------------------
  trino:
    # Pinned to the exact build the provider was live-verified against, the same rule the
    # clickhouse and elasticsearch services follow: the fault names, the page count of an
    # exchange, the `SHOW STATS` shape and the 401 body recorded in docs/providers/trino.md
    # are claims about 476, not about Trino in general. `version()` here returns the bare
    # string "476", so the pin and the engine's own answer are the same token.
    image: trinodb/trino:476
    container_name: libredb-trino
    restart: unless-stopped
    volumes:
      # The object-surface fixture (#789). Mounted at /fixtures and NOT at the
      # /docker-entrypoint-initdb.d most services here use, because that name is a promise
      # this image does not keep: the Trino image has no init-script directory and runs no
      # seed script of its own. The `trino-init` sidecar below is what applies the file, and
      # mounting it on the coordinator too is what makes the re-apply after a restart a
      # one-liner with no bind flags:
      #
      #   docker exec libredb-trino trino --server localhost:8080 \
      #     --file /fixtures/01-object-fixture.sql
      #
      # That re-apply is not optional housekeeping. The `memory` connector holds its schemas,
      # tables, views and functions in the COORDINATOR'S HEAP, so a restart loses all of them
      # and the sidecar, being a one-shot, does not run again by itself.
      - ./docker/trino-init:/fixtures:ro
    ports:
      # 8080 is the client protocol AND the web UI - one port, two surfaces, which is why
      # the provider's default port is a generic number and the dialect is declared rather
      # than inferred from it. There is no second protocol port to publish: Trino has no
      # native wire beyond this HTTP one.
      - "8080:8080"
    healthcheck:
      # The image's own script, not a bare `curl /v1/info`. Measured on a cold start: the
      # statement endpoint answers at ~3.0s, `/v1/info` starts answering 200 at ~5.9s while
      # still reporting `"starting": true`, and only at ~8.8s does it report false. A plain
      # `curl -sf http://localhost:8080/v1/info` would therefore call the service healthy
      # three seconds before it can plan a query. This script reads the port out of
      # /etc/trino/config.properties and greps for `"starting": false`, which is the
      # condition that actually matters.
      test: ["CMD", "/usr/lib/trino/bin/health-check"]
      interval: 5s
      timeout: 5s
      retries: 40
    # No `depends_on`: the image ships the `tpch` catalog configured, so `tpch.tiny.nation`
    # (25 rows) and `tpch.tiny.lineitem` (60175 rows) are queryable the moment the
    # healthcheck passes - generated on read, never stored. `tpcds`, `memory`, `system` and
    # `jmx` are configured too. Point a connection's Database field at `tpch`; `jmx` is what
    # makes the overview's uptime readable, so leave that catalog in place.
    #
    # THERE IS NO ICEBERG CATALOG HERE, and that is a deliberate limit rather than an
    # oversight. A materialized view is the one object kind Trino cannot create without one,
    # and on 476 only a HIVE-METASTORE-backed Iceberg catalog will create one at all.
    #
    # THE CHEAP ROUTE WAS PROBED FOR #789 AND REFUSED, so the next person does not have to
    # spend the same afternoon finding out. The hope was that Trino's Iceberg connector would
    # take `iceberg.catalog.type=jdbc` against the `postgres` service above, giving a
    # materialized-view fixture for the price of one properties file and a warehouse volume
    # with NO new image in this file. Measured on 2026-09-13, the JDBC catalog was brought
    # all the way up and WORKS - `CREATE SCHEMA`, `CREATE TABLE` and a two-row `INSERT` all
    # succeeded - and `CREATE MATERIALIZED VIEW` still answered
    # `createMaterializedView is not supported for Iceberg JDBC catalogs`. Two traps found on
    # the way, both recorded in docs/providers/trino.md: Trino 476 never creates the JDBC
    # catalog's own `iceberg_tables` table, and a `file://` warehouse needs
    # `fs.hadoop.enabled=true` rather than the native local filesystem.
    #
    # So an Iceberg catalog here would mean a metastore service, a warehouse volume and a
    # second image in this file for one object kind. The object surface therefore answers
    # `materialized_view: 0` everywhere on this cluster, which is the TRUE answer for it, and
    # docs/providers/trino.md carries the catalog properties and the exact statements that
    # reproduce the materialized-view measurements on a cluster that does have one.

  trino-init:
    # One-shot sidecar, the same shape as couchbase-init above. The Trino image has no
    # init-script convention of its own, so the seeding is a CLI run rather
    # than a mount the server reads: the CLI ships in this image at /usr/bin/trino, which is
    # why the sidecar reuses the coordinator's image instead of adding a second one.
    image: trinodb/trino:476
    container_name: libredb-trino-init
    restart: "no"
    depends_on:
      trino:
        condition: service_healthy
    volumes:
      - ./docker/trino-init:/fixtures:ro
    # `--server trino:8080`, the compose service name, not localhost: this is a separate
    # container. The image's own entrypoint launches a coordinator, so it is replaced here.
    entrypoint: ["/usr/bin/trino"]
    command:
      - "--server"
      - "trino:8080"
      - "--file"
      - "/fixtures/01-object-fixture.sql"

  cassandra:
    # Pinned to the exact build the provider was live-verified against, the same rule
    # the clickhouse, elasticsearch and trino services follow: the error codes, the
    # `system_views` table set, the type codes for `duration` and `vector`, and the
    # size_estimates behaviour recorded in docs/providers/cassandra.md are claims about
    # 5.0.9 (`system.local.release_version`), not about Cassandra in general.
    image: cassandra:5.0.9
    container_name: libredb-cassandra
    restart: unless-stopped
    # TWO SETTINGS THAT SHIP DISABLED, rewritten into cassandra.yaml before the node
    # starts. Without them this service measures a CONFIGURATION rather than an engine
    # (issue #789): `CREATE MATERIALIZED VIEW` answers "Materialized views are disabled.
    # Enable in cassandra.yaml to use." and `CREATE FUNCTION` answers "User-defined
    # functions are disabled in cassandra.yaml - set user_defined_functions_enabled=true
    # to enable", so the object fixture would build neither and the tree would show two
    # empty folders that look like facts about Cassandra.
    #
    # A sed rather than a mounted cassandra.yaml: the file is ~2000 lines and version
    # specific, so a copy pinned here would silently strip whatever 5.0.10 adds. The
    # image's own entrypoint is still what starts the node. Cassandra 5.0 logs an
    # experimental warning beside the first setting, which is the engine's own wording
    # and not a problem with this service.
    command: >
      bash -c "sed -i
      -e 's/^materialized_views_enabled:.*/materialized_views_enabled: true/'
      -e 's/^user_defined_functions_enabled:.*/user_defined_functions_enabled: true/'
      /etc/cassandra/cassandra.yaml && exec docker-entrypoint.sh cassandra -f"
    environment:
      CASSANDRA_CLUSTER_NAME: libredb-probe
      # 2G of a 4G limit. The image otherwise sizes the heap from the HOST's memory,
      # which on a developer machine claims several gigabytes for a probe node.
      MAX_HEAP_SIZE: 2G
      # HEAP_NEWSIZE is deliberately NOT set. Cassandra 5.0 runs G1 by default and logs
      # "heap_newsize is erroneously set" while ignoring it, so setting it only adds a
      # warning to every start.
    ports:
      # 9042 is the native protocol, the only one this provider speaks. 7000/7001 are
      # internode and 7199 is JMX - the latter is what `nodetool` uses, and no
      # maintenance operation here goes through it (see the provider's empty
      # maintenanceOperations). The old Thrift port 9160 no longer exists.
      - "9042:9042"
    mem_limit: 4g
    healthcheck:
      # `nodetool status` reporting UN (Up/Normal) for a node is the condition that
      # actually matters: `cqlsh` connects a second later, and the native port accepts
      # a socket well before either. MEASURED FROM COLD: 206 seconds to UN on this
      # image, so any fixed sleep a future gate writes will be wrong - the retries
      # below cover 300s and the healthcheck is what a `depends_on` must wait for.
      test: ["CMD-SHELL", "nodetool status | grep -q '^UN'"]
      interval: 10s
      timeout: 10s
      retries: 30
      start_period: 60s
    volumes:
      # THE IMAGE HAS NO INIT-SCRIPT DIRECTORY. Its entrypoint runs `cassandra -f` and
      # never scans a mounted folder, and the node is not accepting CQL at the moment
      # the entrypoint starts anyway. The mount puts the fixture INSIDE the container so
      # it can be applied by hand once `nodetool status` reports UN:
      #
      #   docker exec libredb-cassandra cqlsh -f \
      #     /fixtures/01-object-fixture.cql
      #
      # The target is /fixtures and NOT the /docker-entrypoint-initdb.d every other
      # service here uses, because that name is a promise this image does not keep: it
      # would tell a reader the file runs itself at start, and nothing runs it.
      #
      # The full recipe, including the optional trigger step, is in
      # docs/providers/cassandra.md.
      - ./docker/cassandra-init:/fixtures:ro
    # No seed sidecar, because there is nothing for one to hook into: see the volume
    # above. The object fixture (issue #789) builds keyspace `probe` with three tables, a
    # materialized view, three indexes of two different catalog kinds, a user-defined
    # type, four functions including an overloaded pair, an aggregate and - after the
    # documented trigger step - one trigger. It also creates a keyspace called
    # `system_reports`, which exists to keep the "a system keyspace is excluded by exact
    # name, never by a `system%` prefix" measurement refutable.

  # ---------------------------------------------------------------------------------------
  # Prometheus (issue #1085, #424 Phase 6). One container is the whole server: it scrapes
  # itself, evaluates the rule files beside its configuration and answers the HTTP API the
  # provider reads, so nothing else is needed to exercise it. `prometheus-auth` below is the
  # same image behind basic auth, for the answers only a credential-checking server gives.
  # ---------------------------------------------------------------------------------------
  prometheus:
    # Pinned to the exact build the provider was live-verified against, the same rule the
    # clickhouse and trino services follow: the envelope, the truncation warning, the lexer's
    # reserved words and the 401 answer recorded in tests/fixtures/prometheus/README.md are
    # claims about 3.13.3, the 3.13 LTS line, not about Prometheus in general.
    image: prom/prometheus:v3.13.3
    container_name: libredb-prometheus
    restart: unless-stopped
    # No `command`: the image's own reads /etc/prometheus/prometheus.yml and stores under
    # /prometheus, and it passes neither --web.enable-lifecycle nor --web.enable-admin-api, so
    # this server offers exactly the read API the provider may call (#1085 S9) and nothing
    # that deletes a series or stops the process.
    volumes:
      # The whole configuration, tracked: the scrape jobs and the rule files, each commented
      # with the edge of the provider's object model it exists for. Prometheus reads it at
      # start, so restart the service after an edit; for a change that must reach the
      # fixtures, recreate it with --force-recreate --renew-anon-volumes and capture again.
      - ./docker/prometheus:/etc/prometheus:ro
    ports:
      - "9090:9090"
    healthcheck:
      # /-/ready answers 503 until the storage is open and the configuration is loaded, and 200
      # after, which is the condition that matters; /-/healthy is 200 from the first second.
      # The image is busybox-based and ships wget, not curl (checked with `command -v`
      # before writing this, as the libsql service's comment asks).
      test: ["CMD", "wget", "-q", "-O", "/dev/null", "http://localhost:9090/-/ready"]
      interval: 5s
      timeout: 3s
      retries: 20

  prometheus-auth:
    # The same image and configuration behind the exporter-toolkit web config, which is how
    # Prometheus itself does basic auth. It exists for the answers a stock server cannot give:
    # the 401 status, body and header for a missing, wrong or Bearer credential (#1085 M5).
    # Its own scrape jobs read /metrics without a credential, so its self-scrape targets are
    # `down` with a 401; that is expected, and the data lives on 9090. Start it deliberately:
    #
    #   docker compose -f database-compose.yml --profile prometheus-auth up -d prometheus-auth
    image: prom/prometheus:v3.13.3
    container_name: libredb-prometheus-auth
    profiles: ["prometheus-auth"]
    restart: unless-stopped
    # `command` replaces the image's CMD, so its two defaults are restated before the web
    # config, and there is still no lifecycle or admin flag.
    command:
      - "--config.file=/etc/prometheus/prometheus.yml"
      - "--storage.tsdb.path=/prometheus"
      - "--web.config.file=/etc/prometheus/web-auth.yml"
    volumes:
      - ./docker/prometheus:/etc/prometheus:ro
    ports:
      # 9091 on the host because the service above owns 9090. The provider's default port
      # stays 9090: this is a collision on THIS machine, not a fact about the product.
      - "9091:9090"
    healthcheck:
      # The web config guards every path, /-/ready included, so the check sends the documented
      # test credential from web-auth.yml (user `studio`, password `studio-probe`). A hash that
      # does not match that password therefore shows as a service that never turns healthy,
      # not as a puzzling 401 in the first probe.
      test:
        - CMD
        - wget
        - -q
        - -O
        - /dev/null
        - --header
        - "Authorization: Basic c3R1ZGlvOnN0dWRpby1wcm9iZQ=="
        - http://localhost:9090/-/ready
      interval: 5s
      timeout: 3s
      retries: 20

  # ---------------------------------------------------------------------------------------
  # Apache Kafka (issue #1088). A single combined KRaft node is the default fixture, seeded
  # by a one-shot sidecar and by docker/kafka/seed-binary.ts from the host. Two more
  # fixtures sit behind profiles: `kafka-cluster`, three nodes for replication, and
  # `kafka-auth`, TLS plus SCRAM plus an authorizer, for the answers only such a broker gives.
  # ---------------------------------------------------------------------------------------
  kafka:
    # Pinned to the exact build the provider was live-verified against (docs/providers/kafka.md):
    # the error names, the config sources and the group states captured under
    # tests/fixtures/kafka are claims about 4.3.1, not about Kafka in general.
    # A single combined KRaft node; the listener names follow apache/kafka's own
    # docker/examples single-node plaintext compose.
    image: apache/kafka:4.3.1
    container_name: libredb-kafka
    restart: unless-stopped
    ports:
      # Loopback only, as the postgres service's. No [::1] binding: Docker refuses to start a
      # container whose IPv6 binding it cannot assign, which would break a plain `up`.
      - "127.0.0.1:9092:9092"
    environment:
      KAFKA_NODE_ID: 1
      KAFKA_PROCESS_ROLES: "broker,controller"
      KAFKA_LISTENERS: "CONTROLLER://:29093,PLAINTEXT_HOST://:9092,PLAINTEXT://:19092"
      KAFKA_ADVERTISED_LISTENERS: "PLAINTEXT_HOST://localhost:9092,PLAINTEXT://kafka:19092"
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: "CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT,PLAINTEXT_HOST:PLAINTEXT"
      KAFKA_CONTROLLER_QUORUM_VOTERS: "1@kafka:29093"
      KAFKA_CONTROLLER_LISTENER_NAMES: "CONTROLLER"
      KAFKA_INTER_BROKER_LISTENER_NAME: "PLAINTEXT"
      CLUSTER_ID: "4L6g3nShT-eMCtK--X86sw"
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
      KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR: 1
      KAFKA_TRANSACTION_STATE_LOG_MIN_ISR: 1
      KAFKA_SHARE_COORDINATOR_STATE_TOPIC_REPLICATION_FACTOR: 1
      KAFKA_SHARE_COORDINATOR_STATE_TOPIC_MIN_ISR: 1
      KAFKA_GROUP_INITIAL_REBALANCE_DELAY_MS: 0
      # 512m in place of the image's default 1G, so the heap and the container limit below
      # cannot drift apart. Measured on the seeded fixtures: 150 to 176 MiB live after a GC.
      KAFKA_HEAP_OPTS: "-Xms512m -Xmx512m"
    healthcheck:
      # A socket to the in-container listener through bash's /dev/tcp (the libsql service's
      # form), not kafka-topics.sh: that CLI is a fresh JVM, 1.55 CPU-seconds per probe, which
      # kept each idle broker at ~0.3 of a core; this probe takes 0.02. Enough, because the
      # broker opens its listeners only once started: measured from cold, the socket accepted
      # and ApiVersions answered within 4 ms of each other, and an RF 3 topic created at once.
      test: ["CMD", "bash", "-c", "exec 3<>/dev/tcp/localhost/19092"]
      # Probed every second while starting, so `up --wait` and depends_on see healthy within
      # a second of the broker (from cold: ready in 3 to 4 s); once healthy, once a minute.
      # The start period is three times the ~60 s the start plus seed took on a loaded host,
      # failures inside it do not count, and a connect answers in milliseconds.
      start_period: 180s
      start_interval: 1s
      interval: 60s
      timeout: 5s
      retries: 3
    # Bounded at the maintainer's request: unbounded, the Kafka fixtures loaded the host until
    # it locked up. 1G holds the 512m heap plus the ~140 MiB the JVM keeps outside it plus the
    # ~127 MiB of a CLI JVM run inside it (measured peak 543 MiB with the seed); no swap past
    # it. 1.5 CPUs: the broker plus one CLI JVM, which takes a core while it runs.
    deploy:
      resources:
        limits:
          cpus: "1.5"
          memory: 1G
    memswap_limit: 1G

  kafka-init:
    # One-shot seed, reusing the broker image for its CLI tools (the trino-init precedent).
    # The records the console producer cannot write come from the host afterwards:
    #   bun docker/kafka/seed-binary.ts localhost:9092
    # No data volume: removing the two containers resets the fixture, and the seed appends,
    # so run it once per fresh broker.
    image: apache/kafka:4.3.1
    container_name: libredb-kafka-init
    restart: "no"
    depends_on:
      kafka:
        condition: service_healthy
    volumes:
      - ./docker/kafka/seed.sh:/seed.sh:ro
    entrypoint: ["bash", "/seed.sh", "kafka:19092"]
    # The seed runs one CLI JVM at a time: measured peak 121 MiB and one core.
    deploy:
      resources:
        limits:
          cpus: "1"
          memory: 384M
    memswap_limit: 384M

  # -- Kafka, three-node cluster ----------------------------------------------

  kafka-cluster-1:
    # Three combined KRaft nodes (broker and controller each), one per host port, so the
    # client can reach every advertised broker from the host. The only fixture where a
    # partition has more than one replica, so it is where under-replication and a leader
    # failover are seen live. Profile-gated: start it with
    #   docker compose -f database-compose.yml --profile kafka-cluster up -d
    image: apache/kafka:4.3.1
    container_name: libredb-kafka-cluster-1
    profiles: ["kafka-cluster"]
    restart: unless-stopped
    ports:
      - "127.0.0.1:9192:9192"
    environment: &kafka-cluster-env
      KAFKA_NODE_ID: 1
      KAFKA_PROCESS_ROLES: "broker,controller"
      KAFKA_LISTENERS: "CONTROLLER://:29093,PLAINTEXT_HOST://:9192,PLAINTEXT://:19092"
      KAFKA_ADVERTISED_LISTENERS: "PLAINTEXT_HOST://localhost:9192,PLAINTEXT://kafka-cluster-1:19092"
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: "CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT,PLAINTEXT_HOST:PLAINTEXT"
      KAFKA_CONTROLLER_QUORUM_VOTERS: "1@kafka-cluster-1:29093,2@kafka-cluster-2:29093,3@kafka-cluster-3:29093"
      KAFKA_CONTROLLER_LISTENER_NAMES: "CONTROLLER"
      KAFKA_INTER_BROKER_LISTENER_NAME: "PLAINTEXT"
      CLUSTER_ID: "5L6g3nShT-eMCtK--X86sw"
      KAFKA_DEFAULT_REPLICATION_FACTOR: 3
      KAFKA_MIN_INSYNC_REPLICAS: 2
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 3
      KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR: 3
      KAFKA_TRANSACTION_STATE_LOG_MIN_ISR: 2
      KAFKA_SHARE_COORDINATOR_STATE_TOPIC_REPLICATION_FACTOR: 3
      KAFKA_SHARE_COORDINATOR_STATE_TOPIC_MIN_ISR: 2
      KAFKA_GROUP_INITIAL_REBALANCE_DELAY_MS: 0
      # 512m in place of the image's default 1G, so the heap and the container limit below
      # cannot drift apart. Measured on the seeded fixtures: 150 to 176 MiB live after a GC.
      KAFKA_HEAP_OPTS: "-Xms512m -Xmx512m"
    # The kafka service's probe and its reasons, shared by the three nodes through this anchor.
    healthcheck: &kafka-cluster-health
      test: ["CMD", "bash", "-c", "exec 3<>/dev/tcp/localhost/19092"]
      start_period: 180s
      start_interval: 1s
      interval: 60s
      timeout: 5s
      retries: 3
    # The kafka service's bound and its reasons, per node and shared by all three through
    # this anchor; measured peak 541 to 650 MiB per node with the replicated seed.
    <<: &kafka-cluster-limits
      deploy:
        resources:
          limits:
            cpus: "1.5"
            memory: 1G
      memswap_limit: 1G

  kafka-cluster-2:
    image: apache/kafka:4.3.1
    container_name: libredb-kafka-cluster-2
    profiles: ["kafka-cluster"]
    restart: unless-stopped
    ports:
      - "127.0.0.1:9193:9193"
    environment:
      <<: *kafka-cluster-env
      KAFKA_NODE_ID: 2
      KAFKA_LISTENERS: "CONTROLLER://:29093,PLAINTEXT_HOST://:9193,PLAINTEXT://:19092"
      KAFKA_ADVERTISED_LISTENERS: "PLAINTEXT_HOST://localhost:9193,PLAINTEXT://kafka-cluster-2:19092"
    healthcheck: *kafka-cluster-health
    <<: *kafka-cluster-limits

  kafka-cluster-3:
    image: apache/kafka:4.3.1
    container_name: libredb-kafka-cluster-3
    profiles: ["kafka-cluster"]
    restart: unless-stopped
    ports:
      - "127.0.0.1:9194:9194"
    environment:
      <<: *kafka-cluster-env
      KAFKA_NODE_ID: 3
      KAFKA_LISTENERS: "CONTROLLER://:29093,PLAINTEXT_HOST://:9194,PLAINTEXT://:19092"
      KAFKA_ADVERTISED_LISTENERS: "PLAINTEXT_HOST://localhost:9194,PLAINTEXT://kafka-cluster-3:19092"
    healthcheck: *kafka-cluster-health
    <<: *kafka-cluster-limits

  kafka-cluster-init:
    # The same seed as kafka-init, with every topic at replication factor 3; then, from the
    # host, `bun docker/kafka/seed-binary.ts localhost:9192`.
    image: apache/kafka:4.3.1
    container_name: libredb-kafka-cluster-init
    profiles: ["kafka-cluster"]
    restart: "no"
    depends_on:
      kafka-cluster-1:
        condition: service_healthy
      kafka-cluster-2:
        condition: service_healthy
      kafka-cluster-3:
        condition: service_healthy
    volumes:
      - ./docker/kafka/seed.sh:/seed.sh:ro
    entrypoint: ["bash", "/seed.sh", "kafka-cluster-1:19092", "all", "3"]
    # The seed runs one CLI JVM at a time: measured peak 123 MiB and one core.
    deploy:
      resources:
        limits:
          cpus: "1"
          memory: 384M
    memswap_limit: 384M

  # -- Kafka, TLS and SCRAM with an authorizer --------------------------------

  kafka-auth-certs:
    # Generates a throwaway CA and a localhost broker certificate into a named volume at
    # first start, so no private key is ever committed (the Secret Scan's default rule).
    image: apache/kafka:4.3.1
    container_name: libredb-kafka-auth-certs
    profiles: ["kafka-auth"]
    restart: "no"
    user: "0"
    volumes:
      - kafka-auth-certs:/certs
    entrypoint:
      - bash
      - -c
      - |
        set -e
        cd /certs
        [ -f broker.pem ] && exit 0
        openssl req -x509 -newkey rsa:2048 -nodes -keyout ca.key -out ca.pem -days 3650 -subj "/CN=libredb-kafka-auth-ca"
        openssl req -newkey rsa:2048 -nodes -keyout broker.key -out broker.csr -subj "/CN=localhost"
        printf "subjectAltName=DNS:localhost,IP:127.0.0.1\n" > san.ext
        openssl x509 -req -in broker.csr -CA ca.pem -CAkey ca.key -CAcreateserial -out broker.crt -days 3650 -extfile san.ext
        openssl pkcs8 -topk8 -nocrypt -in broker.key -out broker.pk8
        cat broker.pk8 broker.crt > broker.pem
        chmod 644 ca.pem broker.pem
    # Two RSA keys by openssl: the whole generation was measured to finish inside 32M.
    deploy:
      resources:
        limits:
          cpus: "1"
          memory: 64M
    memswap_limit: 64M

  kafka-auth:
    # TLS plus SCRAM-SHA-512 on the published port, and StandardAuthorizer, so a principal
    # with no ACL sees what such a principal sees. Two traps this configuration avoids:
    # the image's /etc/kafka/docker/configure switches into a JKS-only mode whenever an
    # advertised listener's text contains `SSL://`, so the TLS listener is named EXTERNAL and
    # mapped to SASL_SSL; and inter-broker and admin traffic use a PLAINTEXT INTERNAL listener
    # inside the container only, whose ANONYMOUS principal is a super user, so the SCRAM user
    # is created after start, with no ACL granted to it:
    #
    #   docker exec libredb-kafka-auth /opt/kafka/bin/kafka-configs.sh \
    #     --bootstrap-server localhost:19092 --alter --entity-type users --entity-name reader \
    #     --add-config 'SCRAM-SHA-512=[iterations=8192,password=<a password of your choice>]'
    #   docker cp libredb-kafka-auth:/certs/ca.pem ./kafka-auth-ca.pem
    #
    # No JAAS file and no properties file: the SCRAM login module is set inline below, and
    # nothing would read one.
    image: apache/kafka:4.3.1
    container_name: libredb-kafka-auth
    profiles: ["kafka-auth"]
    restart: unless-stopped
    depends_on:
      kafka-auth-certs:
        condition: service_completed_successfully
    ports:
      # 19094 on the host: the INTERNAL listener's advertised localhost:19092 is the
      # container's own loopback, reached only by `docker exec`.
      - "127.0.0.1:19094:9093"
    volumes:
      - kafka-auth-certs:/certs:ro
    environment:
      KAFKA_NODE_ID: 1
      KAFKA_PROCESS_ROLES: "broker,controller"
      KAFKA_LISTENERS: "CONTROLLER://:29093,INTERNAL://:19092,EXTERNAL://:9093"
      KAFKA_ADVERTISED_LISTENERS: "INTERNAL://localhost:19092,EXTERNAL://localhost:19094"
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: "CONTROLLER:PLAINTEXT,INTERNAL:PLAINTEXT,EXTERNAL:SASL_SSL"
      KAFKA_CONTROLLER_QUORUM_VOTERS: "1@localhost:29093"
      KAFKA_CONTROLLER_LISTENER_NAMES: "CONTROLLER"
      KAFKA_INTER_BROKER_LISTENER_NAME: "INTERNAL"
      CLUSTER_ID: "7L6g3nShT-eMCtK--X86sw"
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
      KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR: 1
      KAFKA_TRANSACTION_STATE_LOG_MIN_ISR: 1
      KAFKA_SHARE_COORDINATOR_STATE_TOPIC_REPLICATION_FACTOR: 1
      KAFKA_SHARE_COORDINATOR_STATE_TOPIC_MIN_ISR: 1
      KAFKA_SASL_ENABLED_MECHANISMS: "SCRAM-SHA-512"
      KAFKA_LISTENER_NAME_EXTERNAL_SCRAM___SHA___512_SASL_JAAS_CONFIG: "org.apache.kafka.common.security.scram.ScramLoginModule required;"
      KAFKA_SSL_KEYSTORE_TYPE: "PEM"
      KAFKA_SSL_KEYSTORE_LOCATION: "/certs/broker.pem"
      KAFKA_AUTHORIZER_CLASS_NAME: "org.apache.kafka.metadata.authorizer.StandardAuthorizer"
      KAFKA_SUPER_USERS: "User:ANONYMOUS;User:admin"
      # 512m in place of the image's default 1G, so the heap and the container limit below
      # cannot drift apart. Measured on the seeded fixtures: 150 to 176 MiB live after a GC.
      KAFKA_HEAP_OPTS: "-Xms512m -Xmx512m"
    # The kafka service's probe and its reasons; the INTERNAL listener is the one the
    # kafka-configs.sh that creates the SCRAM user talks to.
    healthcheck:
      test: ["CMD", "bash", "-c", "exec 3<>/dev/tcp/localhost/19092"]
      start_period: 180s
      start_interval: 1s
      interval: 60s
      timeout: 5s
      retries: 3
    # The kafka service's bound and its reasons; measured peak 547 MiB with the reader and topic.
    deploy:
      resources:
        limits:
          cpus: "1.5"
          memory: 1G
    memswap_limit: 1G

  # ---------------------------------------------------------------------------------------
  # etcd (the etcd provider). One member is the default fixture, seeded by a one-shot sidecar
  # through etcd's own gRPC gateway. Two more fixtures sit behind profiles: `etcd-cluster`,
  # three members for member list, a leader change, one member's defragmentation, a stopped
  # member and a lost quorum; and `etcd-auth`, two TLS servers with RBAC on, one reading client
  # certificates and one taking passwords only. The scripts, the seeded keys, the users and the
  # certificates are described in docker/etcd/README.md.
  # ---------------------------------------------------------------------------------------
  etcd:
    # Pinned to the exact build the provider is verified against, by tag and by digest: the
    # error texts, the gateway's answers and the captures under tests/fixtures/etcd are claims
    # about 3.7.2, not about etcd in general. The image is distroless: etcd, etcdctl and
    # etcdutl, and no shell, so every command below is an exec form.
    image: gcr.io/etcd-development/etcd:v3.7.2@sha256:7c6c239825d00e3f6328a69caafd54be92063acf0c2ce78b8394699f52b75dc3
    container_name: libredb-etcd
    restart: unless-stopped
    # Its own member name and cluster token, as every etcd fixture here: two single-member
    # servers started with the defaults answer with the same cluster and member ids, and a
    # capture must say which server answered it. The advertised client URL is the host's, the
    # address `member list` shows. No data volume: removing the container resets the fixture.
    command:
      - /usr/local/bin/etcd
      - --name=libredb-etcd
      - --initial-cluster-token=libredb-etcd
      - --initial-cluster=libredb-etcd=http://etcd:2380
      - --initial-advertise-peer-urls=http://etcd:2380
      - --listen-peer-urls=http://0.0.0.0:2380
      - --listen-client-urls=http://0.0.0.0:2379
      - --advertise-client-urls=http://127.0.0.1:2379
      - --data-dir=/var/lib/etcd/data
    ports:
      # Loopback only, as the postgres service's.
      - "127.0.0.1:2379:2379"
    environment:
      # The Go runtime collects before it reaches the container's bound below, rather than being
      # killed there.
      GOMEMLIMIT: 900MiB
    healthcheck: &etcd-health
      # etcdctl's own check: a linearizable read, so it passes only once the member has a leader
      # and commits. A Go binary, not a JVM: a probe costs milliseconds.
      test: ["CMD", "etcdctl", "endpoint", "health", "--command-timeout=3s"]
      start_period: 60s
      start_interval: 1s
      interval: 60s
      timeout: 5s
      retries: 3
    # Bounded at the maintainer's request, as the Kafka fixtures are; no swap past it. Measured
    # 12 to 15 MiB with the seed. 1G rather than the other servers' 512M, because this is the
    # server the key-prefix walk and the read bounds are measured on, over a far larger fixture
    # of the measurement's own, and etcd builds a whole Range answer in memory.
    deploy:
      resources:
        limits:
          cpus: "1"
          memory: 1G
    memswap_limit: 1G

  etcd-seed:
    # One-shot seed through the gateway (docker/etcd/seed.sh), which carries a key or a value
    # as base64 of its exact bytes. Idempotent, so it may run again on a seeded server.
    image: alpine/curl:8.21.0@sha256:a1c44bab54d88e18ea9a6a4ecefab7f2d230b968567b78960fcaff8d51b7f067
    container_name: libredb-etcd-seed
    restart: "no"
    depends_on:
      etcd:
        condition: service_healthy
    volumes:
      - ./docker/etcd:/etcd:ro
    entrypoint: ["sh", "/etcd/seed.sh", "http://etcd:2379"]
    <<: &etcd-one-shot-limits
      deploy:
        resources:
          limits:
            cpus: "0.5"
            memory: 64M
      memswap_limit: 64M

  # -- etcd, three-member cluster ---------------------------------------------

  etcd-cluster-1:
    # Three members of one cluster, published on one port at three loopback addresses, so a
    # hosts entry naming all three reaches every member by one name (failover by name); inside
    # the compose network the three share the alias etcd-cluster for the same purpose, where the
    # host cannot bind the addresses. Profile-gated: start it, then seed it, with
    #   docker compose -f database-compose.yml --profile etcd-cluster up -d --wait \
    #     etcd-cluster-1 etcd-cluster-2 etcd-cluster-3
    #   docker compose -f database-compose.yml --profile etcd-cluster up -d etcd-cluster-seed
    image: gcr.io/etcd-development/etcd:v3.7.2@sha256:7c6c239825d00e3f6328a69caafd54be92063acf0c2ce78b8394699f52b75dc3
    container_name: libredb-etcd-cluster-1
    profiles: ["etcd-cluster"]
    restart: unless-stopped
    command:
      - /usr/local/bin/etcd
      - --name=libredb-etcd-cluster-1
      - --initial-cluster-token=libredb-etcd-cluster
      - --initial-cluster=libredb-etcd-cluster-1=http://etcd-cluster-1:2380,libredb-etcd-cluster-2=http://etcd-cluster-2:2380,libredb-etcd-cluster-3=http://etcd-cluster-3:2380
      - --initial-advertise-peer-urls=http://etcd-cluster-1:2380
      - --listen-peer-urls=http://0.0.0.0:2380
      - --listen-client-urls=http://0.0.0.0:2379
      - --advertise-client-urls=http://127.0.0.2:2379
      - --data-dir=/var/lib/etcd/data
    ports:
      - "127.0.0.2:2379:2379"
    networks: &etcd-cluster-alias
      default:
        aliases: ["etcd-cluster"]
    environment: &etcd-member-env
      GOMEMLIMIT: 450MiB
    # The etcd service's probe: a member without a leader turns unhealthy, which is the state a
    # lost quorum is meant to show.
    healthcheck: *etcd-health
    # Measured 15 to 17 MiB per member with the replicated seed; one core each.
    <<: &etcd-member-limits
      deploy:
        resources:
          limits:
            cpus: "1"
            memory: 512M
      memswap_limit: 512M

  etcd-cluster-2:
    image: gcr.io/etcd-development/etcd:v3.7.2@sha256:7c6c239825d00e3f6328a69caafd54be92063acf0c2ce78b8394699f52b75dc3
    container_name: libredb-etcd-cluster-2
    profiles: ["etcd-cluster"]
    restart: unless-stopped
    command:
      - /usr/local/bin/etcd
      - --name=libredb-etcd-cluster-2
      - --initial-cluster-token=libredb-etcd-cluster
      - --initial-cluster=libredb-etcd-cluster-1=http://etcd-cluster-1:2380,libredb-etcd-cluster-2=http://etcd-cluster-2:2380,libredb-etcd-cluster-3=http://etcd-cluster-3:2380
      - --initial-advertise-peer-urls=http://etcd-cluster-2:2380
      - --listen-peer-urls=http://0.0.0.0:2380
      - --listen-client-urls=http://0.0.0.0:2379
      - --advertise-client-urls=http://127.0.0.3:2379
      - --data-dir=/var/lib/etcd/data
    ports:
      - "127.0.0.3:2379:2379"
    networks: *etcd-cluster-alias
    environment: *etcd-member-env
    healthcheck: *etcd-health
    <<: *etcd-member-limits

  etcd-cluster-3:
    image: gcr.io/etcd-development/etcd:v3.7.2@sha256:7c6c239825d00e3f6328a69caafd54be92063acf0c2ce78b8394699f52b75dc3
    container_name: libredb-etcd-cluster-3
    profiles: ["etcd-cluster"]
    restart: unless-stopped
    command:
      - /usr/local/bin/etcd
      - --name=libredb-etcd-cluster-3
      - --initial-cluster-token=libredb-etcd-cluster
      - --initial-cluster=libredb-etcd-cluster-1=http://etcd-cluster-1:2380,libredb-etcd-cluster-2=http://etcd-cluster-2:2380,libredb-etcd-cluster-3=http://etcd-cluster-3:2380
      - --initial-advertise-peer-urls=http://etcd-cluster-3:2380
      - --listen-peer-urls=http://0.0.0.0:2380
      - --listen-client-urls=http://0.0.0.0:2379
      - --advertise-client-urls=http://127.0.0.4:2379
      - --data-dir=/var/lib/etcd/data
    ports:
      - "127.0.0.4:2379:2379"
    networks: *etcd-cluster-alias
    environment: *etcd-member-env
    healthcheck: *etcd-health
    <<: *etcd-member-limits

  etcd-cluster-seed:
    # The same seed as etcd-seed, written once through the first member; raft replicates it.
    image: alpine/curl:8.21.0@sha256:a1c44bab54d88e18ea9a6a4ecefab7f2d230b968567b78960fcaff8d51b7f067
    container_name: libredb-etcd-cluster-seed
    profiles: ["etcd-cluster"]
    restart: "no"
    depends_on:
      etcd-cluster-1:
        condition: service_healthy
      etcd-cluster-2:
        condition: service_healthy
      etcd-cluster-3:
        condition: service_healthy
    volumes:
      - ./docker/etcd:/etcd:ro
    entrypoint: ["sh", "/etcd/seed.sh", "http://etcd-cluster-1:2379"]
    <<: *etcd-one-shot-limits

  # -- etcd, TLS with RBAC on --------------------------------------------------

  etcd-auth-certs:
    # Generates a throwaway CA, the servers' certificate, the users' client certificates and
    # the users' passwords into a named volume at first start (docker/etcd/certs.sh), so no
    # private key and no password is ever committed.
    image: alpine/openssl:3.5.8@sha256:3f25da71f70eba788067daac3f3df03bd1de7a7c52ed89fa93b94ad2c92d986b
    container_name: libredb-etcd-auth-certs
    profiles: ["etcd-auth"]
    restart: "no"
    volumes:
      - etcd-auth-certs:/certs
      - ./docker/etcd:/etcd:ro
    entrypoint: ["sh", "/etcd/certs.sh", "/certs"]
    <<: *etcd-one-shot-limits

  etcd-auth:
    # TLS with --client-cert-auth: every client presents a certificate from the fixture's CA,
    # and with RBAC on its Common Name is the etcd user when no token is sent. The token TTL is
    # 10 seconds of disuse, so an expired token is met live. RBAC is turned on after start by
    # etcd-auth-init. Profile-gated, with etcd-auth-password: start both, then seed them, with
    #   docker compose -f database-compose.yml --profile etcd-auth up -d --wait \
    #     etcd-auth etcd-auth-password
    #   docker compose -f database-compose.yml --profile etcd-auth up -d \
    #     etcd-auth-init etcd-auth-password-init
    image: gcr.io/etcd-development/etcd:v3.7.2@sha256:7c6c239825d00e3f6328a69caafd54be92063acf0c2ce78b8394699f52b75dc3
    container_name: libredb-etcd-auth
    profiles: ["etcd-auth"]
    restart: unless-stopped
    depends_on:
      etcd-auth-certs:
        condition: service_completed_successfully
    command:
      - /usr/local/bin/etcd
      - --name=libredb-etcd-auth
      - --initial-cluster-token=libredb-etcd-auth
      - --initial-cluster=libredb-etcd-auth=http://etcd-auth:2380
      - --initial-advertise-peer-urls=http://etcd-auth:2380
      - --listen-peer-urls=http://0.0.0.0:2380
      - --listen-client-urls=https://0.0.0.0:2379
      - --advertise-client-urls=https://localhost:12379
      - --cert-file=/certs/server.crt
      - --key-file=/certs/server.key
      - --trusted-ca-file=/certs/ca.pem
      - --client-cert-auth
      - --auth-token=simple
      - --auth-token-ttl=10
      - --data-dir=/var/lib/etcd/data
    ports:
      # 12379 on the host, so the three fixtures can run at once; the provider's default port
      # stays 2379.
      - "127.0.0.1:12379:2379"
    volumes:
      - etcd-auth-certs:/certs:ro
    environment: *etcd-member-env
    healthcheck:
      # `auth status` answers with RBAC on or off and needs no credential, and it is a raft
      # request, so it passes only once the member has a leader; `endpoint health` fails
      # as soon as RBAC is on (etcdserver: user name is empty). The certificate is
      # unknown-user's, whose Common Name is no etcd user.
      test:
        - CMD
        - etcdctl
        - --endpoints=https://127.0.0.1:2379
        - --cacert=/certs/ca.pem
        - --cert=/certs/unknown-user.crt
        - --key=/certs/unknown-user.key
        - --command-timeout=3s
        - auth
        - status
      start_period: 60s
      start_interval: 1s
      interval: 60s
      timeout: 5s
      retries: 3
    # The cluster members' bound; measured 18 to 19 MiB with the seed and RBAC.
    <<: *etcd-member-limits

  etcd-auth-init:
    # The seed, then RBAC (docker/etcd/rbac.sh), over TLS with the one certificate that has
    # no Common Name, which etcd's gateway still accepts once RBAC is on (docker/etcd/certs.sh).
    # Idempotent: a second run signs in with root's password first.
    image: alpine/curl:8.21.0@sha256:a1c44bab54d88e18ea9a6a4ecefab7f2d230b968567b78960fcaff8d51b7f067
    container_name: libredb-etcd-auth-init
    profiles: ["etcd-auth"]
    restart: "no"
    depends_on:
      etcd-auth:
        condition: service_healthy
    volumes:
      - etcd-auth-certs:/certs:ro
      - ./docker/etcd:/etcd:ro
    environment:
      ETCD_TLS: "--cacert /certs/ca.pem --cert /certs/gateway-client.crt --key /certs/gateway-client.key"
      ETCD_PASSWORD_DIR: /certs
    entrypoint: ["sh", "-c", "sh /etcd/seed.sh https://etcd-auth:2379 && sh /etcd/rbac.sh https://etcd-auth:2379"]
    <<: *etcd-one-shot-limits

  etcd-auth-password:
    # The same server without --client-cert-auth: TLS that the client verifies and a password,
    # the most common production shape, which --client-cert-auth would rule out, because it
    # applies to every client listener. The same users, roles and token TTL.
    image: gcr.io/etcd-development/etcd:v3.7.2@sha256:7c6c239825d00e3f6328a69caafd54be92063acf0c2ce78b8394699f52b75dc3
    container_name: libredb-etcd-auth-password
    profiles: ["etcd-auth"]
    restart: unless-stopped
    depends_on:
      etcd-auth-certs:
        condition: service_completed_successfully
    command:
      - /usr/local/bin/etcd
      - --name=libredb-etcd-auth-password
      - --initial-cluster-token=libredb-etcd-auth-password
      - --initial-cluster=libredb-etcd-auth-password=http://etcd-auth-password:2380
      - --initial-advertise-peer-urls=http://etcd-auth-password:2380
      - --listen-peer-urls=http://0.0.0.0:2380
      - --listen-client-urls=https://0.0.0.0:2379
      - --advertise-client-urls=https://localhost:12479
      - --cert-file=/certs/server.crt
      - --key-file=/certs/server.key
      - --auth-token=simple
      - --auth-token-ttl=10
      - --data-dir=/var/lib/etcd/data
    ports:
      - "127.0.0.1:12479:2379"
    volumes:
      - etcd-auth-certs:/certs:ro
    environment: *etcd-member-env
    # The etcd-auth service's probe, with no client certificate, which this server never asks for.
    healthcheck:
      test:
        - CMD
        - etcdctl
        - --endpoints=https://127.0.0.1:2379
        - --cacert=/certs/ca.pem
        - --command-timeout=3s
        - auth
        - status
      start_period: 60s
      start_interval: 1s
      interval: 60s
      timeout: 5s
      retries: 3
    # The cluster members' bound; measured 18 to 19 MiB with the seed and RBAC.
    <<: *etcd-member-limits

  etcd-auth-password-init:
    # etcd-auth-init for the password server: the CA only, since this server asks for no
    # client certificate.
    image: alpine/curl:8.21.0@sha256:a1c44bab54d88e18ea9a6a4ecefab7f2d230b968567b78960fcaff8d51b7f067
    container_name: libredb-etcd-auth-password-init
    profiles: ["etcd-auth"]
    restart: "no"
    depends_on:
      etcd-auth-password:
        condition: service_healthy
    volumes:
      - etcd-auth-certs:/certs:ro
      - ./docker/etcd:/etcd:ro
    environment:
      ETCD_TLS: "--cacert /certs/ca.pem"
      ETCD_PASSWORD_DIR: /certs
    entrypoint: ["sh", "-c", "sh /etcd/seed.sh https://etcd-auth-password:2379 && sh /etcd/rbac.sh https://etcd-auth-password:2379"]
    <<: *etcd-one-shot-limits

  # ---------------------------------------------------------------------------------------
  # Oxia (the Oxia provider). One standalone server is the default fixture, three shards, seeded
  # by a one-shot that runs the Oxia CLI inside the Oxia image. Four more fixtures sit behind
  # profiles: `oxia-natural` (two standalone servers that sort keys naturally), `oxia-017` (the
  # same seed on the 0.17 line), `oxia-auth` (TLS and an OIDC token) and `oxia-cluster` (a
  # coordinator and three data servers, for the dial policy). Keys the CLI cannot write are
  # added by hand with tests/live/oxia-seed-raw.ts. The scripts, the seeded keys and the
  # certificates are described in docker/oxia/README.md.
  # ---------------------------------------------------------------------------------------
  oxia:
    # Pinned to the exact build the provider is verified against, by tag and by digest: the
    # captures under tests/fixtures/oxia and the provider's error texts are claims about
    # 0.16.10, not about Oxia in general. The 0.17 line has its own fixture, oxia-017.
    image: oxia/oxia:0.16.10@sha256:da5133e862715b2ea03aada42593d0cb16b7b079bbba2035f82b870a3ccfb322
    container_name: libredb-oxia
    restart: unless-stopped
    # A standalone server advertises the address it listens on, so the container port is the
    # published one. No data volume: removing the container resets the fixture.
    command:
      - oxia
      - standalone
      - --shards
      - "3"
      - --public-addr
      - 0.0.0.0:6648
      - --metrics-addr
      - 0.0.0.0:8080
      - --data-dir
      - /data/db
      - --wal-dir
      - /data/wal
    ports:
      # Loopback only, as the postgres service's.
      - "127.0.0.1:6648:6648"
    environment:
      # The Go runtime collects before it reaches the container's bound below, rather than being
      # killed there.
      GOMEMLIMIT: 900MiB
    healthcheck: &oxia-standalone-health
      # A list through the public listener, which exits 0 only once the shard map is served, so
      # it also catches a server whose assignments never arrive. A standalone server has no
      # internal listener for `oxia health` (measured on 0.16.10: connection refused on 6649).
      # The authority is localhost:6648, a plain host:port, which every server accepts.
      test: ["CMD", "oxia", "client", "-a", "localhost:6648", "--request-timeout", "3s", "list", "-s", "/", "-e", "/0"]
      start_period: 60s
      start_interval: 1s
      interval: 60s
      timeout: 5s
      retries: 3
    # Bounded at the maintainer's request, as the Kafka fixtures are; no swap past it. A seeded
    # 0.17.1 server measured 217 MiB and a seeded 0.16.10 server 101 MiB, so 1G leaves room for
    # the 17 MiB value's WAL and the 20,000 bulk keys of tests/live/oxia-seed-raw.ts.
    deploy:
      resources:
        limits:
          cpus: "1"
          memory: 1G
    memswap_limit: 1G

  oxia-seed:
    # One-shot seed through the Oxia CLI of the server's own image (docker/oxia/seed.sh). It
    # wipes the namespace first, so it may run again on a seeded server.
    image: oxia/oxia:0.16.10@sha256:da5133e862715b2ea03aada42593d0cb16b7b079bbba2035f82b870a3ccfb322
    container_name: libredb-oxia-seed
    restart: "no"
    depends_on:
      oxia:
        condition: service_healthy
    volumes:
      - ./docker/oxia:/seed:ro
    entrypoint: ["sh", "/seed/seed.sh", "oxia:6648", "full"]
    <<: &oxia-one-shot-limits
      deploy:
        resources:
          limits:
            cpus: "0.5"
            memory: 256M
      memswap_limit: 256M

  # -- Oxia, natural key order -------------------------------------------------

  oxia-natural:
    # The natural key order, which a namespace fixes at creation, on two shards: the small key
    # set, with keys whose first byte sorts below /. Profile-gated with oxia-natural-blind:
    #   docker compose -f database-compose.yml --profile oxia-natural up -d --wait \
    #     oxia-natural oxia-natural-blind
    #   docker compose -f database-compose.yml --profile oxia-natural up oxia-natural-seed
    image: oxia/oxia:0.16.10@sha256:da5133e862715b2ea03aada42593d0cb16b7b079bbba2035f82b870a3ccfb322
    container_name: libredb-oxia-natural
    profiles: ["oxia-natural"]
    restart: unless-stopped
    command: &oxia-natural-command
      - oxia
      - standalone
      - --shards
      - "2"
      - --public-addr
      - 0.0.0.0:6648
      - --metrics-addr
      - 0.0.0.0:8080
      - --data-dir
      - /data/db
      - --wal-dir
      - /data/wal
      - --key-sorting
      - natural
    ports:
      - "127.0.0.1:6658:6648"
    environment:
      GOMEMLIMIT: 450MiB
    healthcheck: *oxia-standalone-health
    # A small key set: 512M, half the default server's bound.
    deploy:
      resources:
        limits:
          cpus: "1"
          memory: 512M
    memswap_limit: 512M

  oxia-natural-blind:
    # The blind spot of the order probe: a natural namespace whose listed keys each begin with
    # a byte below /. 605 short keys: 256M.
    image: oxia/oxia:0.16.10@sha256:da5133e862715b2ea03aada42593d0cb16b7b079bbba2035f82b870a3ccfb322
    container_name: libredb-oxia-natural-blind
    profiles: ["oxia-natural"]
    restart: unless-stopped
    command: *oxia-natural-command
    ports:
      - "127.0.0.1:6659:6648"
    environment:
      GOMEMLIMIT: 200MiB
    healthcheck: *oxia-standalone-health
    deploy:
      resources:
        limits:
          cpus: "1"
          memory: 256M
    memswap_limit: 256M

  oxia-natural-seed:
    # Both natural servers, one after the other, from inside the oxia-natural profile, so a
    # plain up never starts a profiled server.
    image: oxia/oxia:0.16.10@sha256:da5133e862715b2ea03aada42593d0cb16b7b079bbba2035f82b870a3ccfb322
    container_name: libredb-oxia-natural-seed
    profiles: ["oxia-natural"]
    restart: "no"
    depends_on:
      oxia-natural:
        condition: service_healthy
      oxia-natural-blind:
        condition: service_healthy
    volumes:
      - ./docker/oxia:/seed:ro
    entrypoint: ["sh", "-c", "sh /seed/seed.sh oxia-natural:6648 small && sh /seed/seed.sh oxia-natural-blind:6648 blind"]
    <<: *oxia-one-shot-limits

  # -- Oxia, the 0.17 line -----------------------------------------------------

  oxia-017:
    # The same server and seed on 0.17.1, pinned by digest: the line the provider doc
    # recommends, and the captures under tests/fixtures/oxia/0.17.1 are claims about it.
    # Profile-gated:
    #   docker compose -f database-compose.yml --profile oxia-017 up -d --wait oxia-017
    #   docker compose -f database-compose.yml --profile oxia-017 up oxia-017-seed
    image: oxia/oxia:0.17.1@sha256:165bf4f3803153f23be3ba699f6430ab1463cdeaa46e341ff32c3eaed0d1b7d6
    container_name: libredb-oxia-017
    profiles: ["oxia-017"]
    restart: unless-stopped
    command:
      - oxia
      - standalone
      - --shards
      - "3"
      - --public-addr
      - 0.0.0.0:6648
      - --metrics-addr
      - 0.0.0.0:8080
      - --data-dir
      - /data/db
      - --wal-dir
      - /data/wal
    ports:
      - "127.0.0.1:6668:6648"
    environment:
      GOMEMLIMIT: 900MiB
    healthcheck: *oxia-standalone-health
    # A seeded 0.17.1 server measured 217 MiB.
    deploy:
      resources:
        limits:
          cpus: "1"
          memory: 1G
    memswap_limit: 1G

  oxia-017-seed:
    # The full seed with the 0.17.1 CLI.
    image: oxia/oxia:0.17.1@sha256:165bf4f3803153f23be3ba699f6430ab1463cdeaa46e341ff32c3eaed0d1b7d6
    container_name: libredb-oxia-017-seed
    profiles: ["oxia-017"]
    restart: "no"
    depends_on:
      oxia-017:
        condition: service_healthy
    volumes:
      - ./docker/oxia:/seed:ro
    entrypoint: ["sh", "/seed/seed.sh", "oxia-017:6648", "full"]
    <<: *oxia-one-shot-limits

  # -- Oxia, TLS with an OIDC token --------------------------------------------

  oxia-auth-certs:
    # Generates a throwaway CA, the server certificate, a client pair, the JWT key pair and the
    # tokens into a named volume at first start (docker/oxia/certs.sh), so no certificate, key
    # or token is ever committed.
    image: alpine/openssl:3.5.8@sha256:3f25da71f70eba788067daac3f3df03bd1de7a7c52ed89fa93b94ad2c92d986b
    container_name: libredb-oxia-auth-certs
    profiles: ["oxia-auth"]
    restart: "no"
    volumes:
      - oxia-auth-material:/certs
      - ./docker/oxia:/seed:ro
    entrypoint: ["sh", "/seed/certs.sh", "/certs"]
    deploy:
      resources:
        limits:
          cpus: "0.5"
          memory: 64M
    memswap_limit: 64M

  oxia-auth:
    # A coordinator and a data server in one container: TLS on the public listener and the OIDC
    # provider with a static key, so a token is checked without an issuer endpoint. The
    # coordinator's memory metadata is rebuilt on a restart, and the server keeps its shards.
    # Not seeded: the 0.16.10 CLI has no TLS or token flag. Profile-gated:
    #   docker compose -f database-compose.yml --profile oxia-auth up -d --wait oxia-auth
    image: oxia/oxia:0.16.10@sha256:da5133e862715b2ea03aada42593d0cb16b7b079bbba2035f82b870a3ccfb322
    container_name: libredb-oxia-auth
    profiles: ["oxia-auth"]
    restart: unless-stopped
    depends_on:
      oxia-auth-certs:
        condition: service_completed_successfully
    command:
      - sh
      - -c
      - |
        oxia coordinator --cconfig /seed/cluster-auth.yaml --metadata memory -i 0.0.0.0:6652 -a 0.0.0.0:6651 -m 0.0.0.0:6653 &
        exec oxia server -p 0.0.0.0:6678 -i 0.0.0.0:6649 -m 0.0.0.0:8080 --data-dir /data/db --wal-dir /data/wal \
          --tls-cert-file /certs/server.crt --tls-key-file /certs/server.key \
          --auth-provider-name oidc \
          --auth-provider-params '{"issuers":{"https://issuer.libredb-fixture.invalid":{"allowedAudiences":"oxia","userNameClaim":"sub","staticKeyFile":"/certs/jwt.pub"}}}'
    ports:
      # The port cluster-auth.yaml advertises, the same on the host and in the container.
      - "127.0.0.1:6678:6678"
    volumes:
      - oxia-auth-material:/certs:ro
      - ./docker/oxia:/seed:ro
    environment:
      GOMEMLIMIT: 900MiB
    healthcheck: &oxia-internal-health
      # `oxia health` on the internal listener, which answers SERVING without TLS or a token;
      # the 0.16.10 CLI has no TLS or token flag for the public one (measured on the shared
      # TLS and OIDC probes).
      test: ["CMD", "oxia", "health", "--host", "localhost", "--port", "6649", "--timeout", "3s"]
      start_period: 60s
      start_interval: 1s
      interval: 60s
      timeout: 5s
      retries: 3
    deploy:
      resources:
        limits:
          cpus: "1"
          memory: 1G
    memswap_limit: 1G

  # -- Oxia, a coordinator and three data servers ------------------------------

  oxia-cluster-coordinator:
    # The cluster of docker/oxia/cluster.yaml, for the dial policy: each shard leader is
    # advertised at its own loopback port. Profile-gated:
    #   docker compose -f database-compose.yml --profile oxia-cluster up -d --wait \
    #     oxia-cluster-coordinator oxia-cluster-1 oxia-cluster-2 oxia-cluster-3
    # An empty cluster-mode server measured 24 MiB.
    image: oxia/oxia:0.16.10@sha256:da5133e862715b2ea03aada42593d0cb16b7b079bbba2035f82b870a3ccfb322
    container_name: libredb-oxia-cluster-coordinator
    profiles: ["oxia-cluster"]
    restart: unless-stopped
    command:
      - oxia
      - coordinator
      - --cconfig
      - /seed/cluster.yaml
      - --metadata
      - memory
      - -i
      - 0.0.0.0:6652
      - -a
      - 0.0.0.0:6651
      - -m
      - 0.0.0.0:6653
    volumes:
      - ./docker/oxia:/seed:ro
    environment:
      GOMEMLIMIT: 200MiB
    healthcheck:
      # The coordinator's internal listener answers `oxia health` (measured on 0.16.10).
      test: ["CMD", "oxia", "health", "--host", "localhost", "--port", "6652", "--timeout", "3s"]
      start_period: 60s
      start_interval: 1s
      interval: 60s
      timeout: 5s
      retries: 3
    deploy:
      resources:
        limits:
          cpus: "1"
          memory: 256M
    memswap_limit: 256M

  oxia-cluster-1:
    # A cluster advertises the public address of cluster.yaml, so the container listens on the
    # published port. The check is on the internal listener: a list from inside one container is
    # sent to leaders on the other servers, whose advertised ports are the host's.
    image: oxia/oxia:0.16.10@sha256:da5133e862715b2ea03aada42593d0cb16b7b079bbba2035f82b870a3ccfb322
    container_name: libredb-oxia-cluster-1
    profiles: ["oxia-cluster"]
    restart: unless-stopped
    command: ["oxia", "server", "-p", "0.0.0.0:6671", "-i", "0.0.0.0:6649", "-m", "0.0.0.0:8080", "--data-dir", "/data/db", "--wal-dir", "/data/wal"]
    ports:
      - "127.0.0.1:6671:6671"
    environment: &oxia-cluster-env
      GOMEMLIMIT: 450MiB
    healthcheck: *oxia-internal-health
    <<: &oxia-cluster-server-limits
      deploy:
        resources:
          limits:
            cpus: "1"
            memory: 512M
      memswap_limit: 512M

  oxia-cluster-2:
    image: oxia/oxia:0.16.10@sha256:da5133e862715b2ea03aada42593d0cb16b7b079bbba2035f82b870a3ccfb322
    container_name: libredb-oxia-cluster-2
    profiles: ["oxia-cluster"]
    restart: unless-stopped
    command: ["oxia", "server", "-p", "0.0.0.0:6672", "-i", "0.0.0.0:6649", "-m", "0.0.0.0:8080", "--data-dir", "/data/db", "--wal-dir", "/data/wal"]
    ports:
      - "127.0.0.1:6672:6672"
    environment: *oxia-cluster-env
    healthcheck: *oxia-internal-health
    <<: *oxia-cluster-server-limits

  oxia-cluster-3:
    image: oxia/oxia:0.16.10@sha256:da5133e862715b2ea03aada42593d0cb16b7b079bbba2035f82b870a3ccfb322
    container_name: libredb-oxia-cluster-3
    profiles: ["oxia-cluster"]
    restart: unless-stopped
    command: ["oxia", "server", "-p", "0.0.0.0:6673", "-i", "0.0.0.0:6649", "-m", "0.0.0.0:8080", "--data-dir", "/data/db", "--wal-dir", "/data/wal"]
    ports:
      - "127.0.0.1:6673:6673"
    environment: *oxia-cluster-env
    healthcheck: *oxia-internal-health
    <<: *oxia-cluster-server-limits

  # ---------------------------------------------------------------------------------------
  # Milvus (the milvus provider). One standalone server with authorization on is the default
  # fixture, seeded by a one-shot Python sidecar; two TLS servers sit behind the `milvus-tls`
  # profile, one-way TLS and mutual TLS. Every server follows Milvus's standalone_embed.sh at
  # tag v3.0.2 with three measured changes: a named volume per server, because the image runs
  # as uid 999 and the script's bind mount crashed it with exit code 134; image v3.0.2, where
  # the script at that tag pins v3.0.1; and, for TLS, REST on a listener of its own, because
  # TLS forces separate ports. docker/milvus/README.md describes the servers, the seeded
  # objects, the users and the certificates.
  # ---------------------------------------------------------------------------------------
  milvus:
    # Pinned to the exact build the vector fixtures were captured from, by tag and by digest:
    # the captures under tests/fixtures/vector are claims about 3.0.2.
    image: milvusdb/milvus:v3.0.2@sha256:5f13bf88e110a517911c3e6dd8172454e90042c21e606a868084615a4302c8a0
    container_name: libredb-milvus
    # During the research the embedded etcd of one server stalled on fdatasync for 7.8 s, lost
    # its lease and exited with code 80, so the server restarts; a harness checks every
    # service's health first and fails loudly on an exited or unhealthy one, with no retry.
    restart: unless-stopped
    command: ["milvus", "run", "standalone"]
    security_opt: ["seccomp:unconfined"]
    # Authorization is on. root keeps Milvus's documented default password, which nothing here
    # sets: it is the server's built-in default.
    environment: &milvus-env
      ETCD_USE_EMBED: "true"
      ETCD_DATA_DIR: /var/lib/milvus/etcd
      ETCD_CONFIG_PATH: /milvus/configs/embedEtcd.yaml
      COMMON_STORAGETYPE: local
      DEPLOY_MODE: STANDALONE
      COMMON_SECURITY_AUTHORIZATIONENABLED: "true"
    volumes:
      - milvus-data:/var/lib/milvus
      - ./docker/milvus/embedEtcd.yaml:/milvus/configs/embedEtcd.yaml
      - ./docker/milvus/user.yaml:/milvus/configs/user.yaml
    ports:
      # gRPC and REST share 19530. The management port 9091 answers without authentication on
      # 3.0.2, so it is published on loopback alone, as 19091, for the live check's telemetry
      # read; 9091 on the host is prometheus-auth's. The embedded etcd's 2379 is not published.
      - "127.0.0.1:19530:19530"
      - "127.0.0.1:19091:9091"
    healthcheck: &milvus-health
      # The management port's own probe, plain HTTP inside the container on every server.
      test: ["CMD", "curl", "-f", "http://localhost:9091/healthz"]
      start_period: 90s
      start_interval: 2s
      interval: 30s
      timeout: 20s
      retries: 3
    # Bounded at the maintainer's request; no swap past it. Measured 156 to 292 MiB after
    # seeding during the research.
    <<: &milvus-limits
      deploy:
        resources:
          limits:
            cpus: "2"
            memory: 4G
      memswap_limit: 4G

  milvus-seed:
    # One-shot seed (docker/milvus/seed.py) in a pinned Python image, which installs pymilvus
    # and its dependencies from docker/milvus/requirements.txt, pinned with hashes. It creates
    # what is missing and leaves what exists, so it may run again on a seeded server, and it
    # generates the passwords of the users reader and nobody into the milvus-credentials volume.
    # pip writes to stderr, so `run ... milvus-seed ... --manifest` prints the manifest alone.
    # requirements.txt hashes the linux/amd64 wheels, so the seed runs as linux/amd64 everywhere.
    image: python:3.12-slim@sha256:dddfd7e07f9d15aeeca61529320492139d21cac7f0070c00609243e51e4e0016
    platform: linux/amd64
    container_name: libredb-milvus-seed
    restart: "no"
    depends_on:
      milvus:
        condition: service_healthy
    volumes:
      - ./docker/milvus:/seed:ro
      - milvus-credentials:/credentials
    environment: &seed-env
      PIP_DISABLE_PIP_VERSION_CHECK: "1"
      PIP_ROOT_USER_ACTION: ignore
      PYTHONDONTWRITEBYTECODE: "1"
    entrypoint:
      - sh
      - -c
      - pip install --quiet --no-cache-dir --require-hashes -r /seed/requirements.txt 1>&2 && exec python /seed/seed.py "$$@"
      - milvus-seed
    command: ["--uri", "http://milvus:19530", "--credentials", "/credentials"]
    <<: &vector-seed-limits
      deploy:
        resources:
          limits:
            cpus: "1"
            memory: 1G
      memswap_limit: 1G

  # -- Milvus, one-way and mutual TLS -------------------------------------------

  milvus-certs:
    # Generates a throwaway CA, the servers' certificate and the client certificates into a
    # named volume at first start (docker/milvus/certs.sh), so no private key is ever committed.
    image: alpine/openssl:3.5.8@sha256:3f25da71f70eba788067daac3f3df03bd1de7a7c52ed89fa93b94ad2c92d986b
    container_name: libredb-milvus-certs
    profiles: ["milvus-tls"]
    restart: "no"
    volumes:
      - milvus-certs:/certs
      - ./docker/milvus:/milvus:ro
    entrypoint: ["sh", "/milvus/certs.sh", "/certs"]
    <<: &vector-one-shot-limits
      deploy:
        resources:
          limits:
            cpus: "0.5"
            memory: 64M
      memswap_limit: 64M

  milvus-tls:
    # tlsMode 1: the server presents its certificate and asks for none. REST moves to its own
    # listener, 8080, published as 19541. Profile-gated, with milvus-mtls.
    image: milvusdb/milvus:v3.0.2@sha256:5f13bf88e110a517911c3e6dd8172454e90042c21e606a868084615a4302c8a0
    container_name: libredb-milvus-tls
    profiles: ["milvus-tls"]
    restart: unless-stopped
    depends_on:
      milvus-certs:
        condition: service_completed_successfully
    command: ["milvus", "run", "standalone"]
    security_opt: ["seccomp:unconfined"]
    environment:
      <<: *milvus-env
      COMMON_SECURITY_TLSMODE: "1"
      PROXY_HTTP_PORT: "8080"
      TLS_SERVERPEMPATH: /milvus/tls/server.pem
      TLS_SERVERKEYPATH: /milvus/tls/server.key
      TLS_CAPEMPATH: /milvus/tls/ca.pem
    volumes:
      - milvus-tls-data:/var/lib/milvus
      - milvus-certs:/milvus/tls:ro
      - ./docker/milvus/embedEtcd.yaml:/milvus/configs/embedEtcd.yaml
      - ./docker/milvus/user.yaml:/milvus/configs/user.yaml
    ports:
      - "127.0.0.1:19531:19530"
      - "127.0.0.1:19541:8080"
    healthcheck: *milvus-health
    <<: *milvus-limits

  milvus-mtls:
    # tlsMode 2: the server also asks for a client certificate issued by the fixture's CA. Only
    # gRPC is published; REST keeps its own listener inside the container.
    image: milvusdb/milvus:v3.0.2@sha256:5f13bf88e110a517911c3e6dd8172454e90042c21e606a868084615a4302c8a0
    container_name: libredb-milvus-mtls
    profiles: ["milvus-tls"]
    restart: unless-stopped
    depends_on:
      milvus-certs:
        condition: service_completed_successfully
    command: ["milvus", "run", "standalone"]
    security_opt: ["seccomp:unconfined"]
    environment:
      <<: *milvus-env
      COMMON_SECURITY_TLSMODE: "2"
      PROXY_HTTP_PORT: "8080"
      TLS_SERVERPEMPATH: /milvus/tls/server.pem
      TLS_SERVERKEYPATH: /milvus/tls/server.key
      TLS_CAPEMPATH: /milvus/tls/ca.pem
    volumes:
      - milvus-mtls-data:/var/lib/milvus
      - milvus-certs:/milvus/tls:ro
      - ./docker/milvus/embedEtcd.yaml:/milvus/configs/embedEtcd.yaml
      - ./docker/milvus/user.yaml:/milvus/configs/user.yaml
    ports:
      - "127.0.0.1:19532:19530"
    healthcheck: *milvus-health
    <<: *milvus-limits

  # ---------------------------------------------------------------------------------------
  # Qdrant (the qdrant provider). One server with no key is the default fixture, seeded by a
  # one-shot Python sidecar; three keyed servers sit behind profiles: `qdrant-auth`, with an
  # admin key, a read-only key and JWT RBAC, and `qdrant-tls`, with one-way TLS and with TLS
  # that verifies the client's certificate. The keys and the TLS settings reach each keyed
  # server as the local.yaml qdrant-keys generates into a volume, never as an environment
  # variable here. No server publishes gRPC 6334 or the internal port 6335, which the provider
  # never dials, and no server has a data volume: removing its container resets it.
  # docker/qdrant/README.md describes the servers, the seeded collections and the keys.
  # ---------------------------------------------------------------------------------------
  qdrant:
    # The GHCR mirror of the build the vector fixtures were captured from, by tag and by
    # digest; it reports commit 6ab21cac.
    image: ghcr.io/qdrant/qdrant/qdrant:v1.19.1@sha256:808d42530f48a2b88abe960165ffe81e9ec71f505d72e6404145444e0e085822
    container_name: libredb-qdrant
    restart: unless-stopped
    environment: &qdrant-env
      # A server otherwise reports to telemetry.qdrant.io every hour.
      QDRANT__TELEMETRY_DISABLED: "true"
    ports:
      - "127.0.0.1:6333:6333"
    healthcheck: &qdrant-http-health
      # /readyz needs no key. The image has bash and no curl, so the probe speaks HTTP itself.
      test:
        - CMD
        - bash
        - -c
        - exec 3<>/dev/tcp/127.0.0.1/6333 && printf 'GET /readyz HTTP/1.0\r\n\r\n' >&3 && head -n 1 <&3 | grep -q ' 200 '
      start_period: 30s
      start_interval: 1s
      interval: 30s
      timeout: 5s
      retries: 3
    # Bounded at the maintainer's request; no swap past it. Measured 44 to 80 MiB after seeding
    # during the research.
    <<: &qdrant-limits
      deploy:
        resources:
          limits:
            cpus: "2"
            memory: 2G
      memswap_limit: 2G

  qdrant-seed:
    # One-shot seed (docker/qdrant/seed.py) in a pinned Python image, which installs
    # qdrant-client and its dependencies from docker/qdrant/requirements.txt, pinned with
    # hashes. It creates what is missing and leaves what exists. It mounts the keys read-only,
    # so the same one-shot seeds qdrant-auth with --api-key-file (docker/qdrant/README.md).
    # requirements.txt hashes the linux/amd64 wheels, so the seed runs as linux/amd64 everywhere.
    image: python:3.14-slim@sha256:0741d101873c12ab927e6f8653feb8862b9bd58771177acb1b885b95141f91b4
    platform: linux/amd64
    container_name: libredb-qdrant-seed
    restart: "no"
    depends_on:
      qdrant:
        condition: service_healthy
    volumes:
      - ./docker/qdrant:/seed:ro
      - qdrant-keys:/keys:ro
    environment: *seed-env
    entrypoint:
      - sh
      - -c
      - pip install --quiet --no-cache-dir --require-hashes -r /seed/requirements.txt 1>&2 && exec python /seed/seed.py "$$@"
      - qdrant-seed
    command: ["--url", "http://qdrant:6333"]
    <<: *vector-seed-limits

  # -- Qdrant, keys, JWT and TLS -------------------------------------------------

  qdrant-keys:
    # Generates each keyed server's admin and read-only keys, its local.yaml and the TLS
    # material into a named volume at first start (docker/qdrant/keys.sh), so no key and no
    # private key is ever committed.
    image: alpine/openssl:3.5.8@sha256:3f25da71f70eba788067daac3f3df03bd1de7a7c52ed89fa93b94ad2c92d986b
    container_name: libredb-qdrant-keys
    profiles: ["qdrant-auth", "qdrant-tls"]
    restart: "no"
    volumes:
      - qdrant-keys:/keys
      - ./docker/qdrant:/qdrant-scripts:ro
    entrypoint: ["sh", "/qdrant-scripts/keys.sh", "/keys"]
    <<: *vector-one-shot-limits

  qdrant-auth:
    image: ghcr.io/qdrant/qdrant/qdrant:v1.19.1@sha256:808d42530f48a2b88abe960165ffe81e9ec71f505d72e6404145444e0e085822
    container_name: libredb-qdrant-auth
    profiles: ["qdrant-auth"]
    restart: unless-stopped
    depends_on:
      qdrant-keys:
        condition: service_completed_successfully
    entrypoint: ["bash", "-c", "cp /keys/auth/local.yaml /qdrant/config/local.yaml && exec ./entrypoint.sh"]
    environment:
      <<: *qdrant-env
      # inference listener must receive nothing
      QDRANT__INFERENCE__ADDRESS: http://host.docker.internal:18904/infer
    extra_hosts:
      - "host.docker.internal:host-gateway"
    volumes:
      - qdrant-keys:/keys:ro
    ports:
      - "127.0.0.1:6343:6333"
    healthcheck: *qdrant-http-health
    <<: *qdrant-limits

  qdrant-tls:
    # TLS on REST: the server presents its certificate and asks for none.
    image: ghcr.io/qdrant/qdrant/qdrant:v1.19.1@sha256:808d42530f48a2b88abe960165ffe81e9ec71f505d72e6404145444e0e085822
    container_name: libredb-qdrant-tls
    profiles: ["qdrant-tls"]
    restart: unless-stopped
    depends_on:
      qdrant-keys:
        condition: service_completed_successfully
    entrypoint: ["bash", "-c", "cp /keys/tls/local.yaml /qdrant/config/local.yaml && exec ./entrypoint.sh"]
    environment: *qdrant-env
    volumes:
      - qdrant-keys:/keys:ro
    ports:
      - "127.0.0.1:6353:6333"
    healthcheck: &qdrant-tcp-health
      # The listener speaks TLS, which bash cannot, so the probe only opens the socket.
      test: ["CMD", "bash", "-c", "</dev/tcp/127.0.0.1/6333"]
      start_period: 30s
      start_interval: 1s
      interval: 30s
      timeout: 5s
      retries: 3
    <<: *qdrant-limits

  qdrant-mtls:
    # TLS with verify_https_client_certificate: the server also asks for a client certificate
    # issued by the fixture's CA.
    image: ghcr.io/qdrant/qdrant/qdrant:v1.19.1@sha256:808d42530f48a2b88abe960165ffe81e9ec71f505d72e6404145444e0e085822
    container_name: libredb-qdrant-mtls
    profiles: ["qdrant-tls"]
    restart: unless-stopped
    depends_on:
      qdrant-keys:
        condition: service_completed_successfully
    entrypoint: ["bash", "-c", "cp /keys/mtls/local.yaml /qdrant/config/local.yaml && exec ./entrypoint.sh"]
    environment: *qdrant-env
    volumes:
      - qdrant-keys:/keys:ro
    ports:
      - "127.0.0.1:6363:6333"
    healthcheck: *qdrant-tcp-health
    <<: *qdrant-limits

  # ---------------------------------------------------------------------------------------
  # InfluxDB (the influxdb and influxdb3 providers). Three servers, one per line the providers
  # are verified against: 1.13.1 and 2.9.1, which the influxdb type reads over the v1 /query
  # API, and 3.12.0 Core, which both types read. Each is pinned by tag and by digest, and each
  # has authentication on with the fixed test credentials below, as the clickhouse and neo4j
  # services spell theirs; the read principals are added by the seed. influxdb-seed is a
  # one-shot that runs docker/influxdb/seed.sh, the only writer of these fixtures: it creates
  # the 1.x reader (READ on home), the 2.x read-only token for bucket home, which it keeps in
  # the influxdb2-read-token volume, and the home and edge data on each server.
  # influxdb3-filelimit, behind its profile, is the file-limit fixture (--query-file-limit 1),
  # seeded by hand. No server has a named data volume; the 1.x and 2.x images declare anonymous
  # ones, which survive --force-recreate, so a reset removes them with the container
  # (`rm -s -f -v`), and the seed writes the server again with fresh timestamps.
  # docker/influxdb/README.md describes the servers, the principals and the seed data.
  # ---------------------------------------------------------------------------------------
  influxdb1:
    image: influxdb:1.13.1@sha256:3e3913d3b7512d1749922c8183bbf2a76973dd9f98e1a1e3249c652ec1576fc0
    container_name: libredb-influxdb1
    restart: unless-stopped
    environment:
      # The image's entrypoint creates the admin user and database home at first start.
      INFLUXDB_HTTP_AUTH_ENABLED: "true"
      INFLUXDB_ADMIN_USER: admin
      INFLUXDB_ADMIN_PASSWORD: password123
      INFLUXDB_DB: home
      # A server otherwise reports to usage.influxdata.com every 24 hours.
      INFLUXDB_REPORTING_DISABLED: "true"
    ports:
      - "127.0.0.1:8087:8086"
    healthcheck: &influxdb-ping-health
      # /ping needs no credential on 1.x and 2.x and answers 204; the image carries curl.
      test: ["CMD", "curl", "-sf", "-o", "/dev/null", "http://127.0.0.1:8086/ping"]
      start_period: 30s
      start_interval: 1s
      interval: 30s
      timeout: 5s
      retries: 3
    # Bounded as the Qdrant fixtures are; no swap past it. 2 GiB leaves room for the hand-run
    # bench database (docker/influxdb/README.md).
    <<: &influxdb-limits
      deploy:
        resources:
          limits:
            cpus: "2"
            memory: 2G
      memswap_limit: 2G

  influxdb2:
    image: influxdb:2.9.1@sha256:db0bdab1e5ad5ee899c127b8c13d9c986a3ced78cd9200dd80a1064bf1533b6e
    container_name: libredb-influxdb2
    restart: unless-stopped
    environment:
      # The image's entrypoint runs the initial setup at first start: user admin, org libredb,
      # bucket home and this all-access operator token.
      DOCKER_INFLUXDB_INIT_MODE: setup
      DOCKER_INFLUXDB_INIT_USERNAME: admin
      DOCKER_INFLUXDB_INIT_PASSWORD: password123
      DOCKER_INFLUXDB_INIT_ORG: libredb
      DOCKER_INFLUXDB_INIT_BUCKET: home
      DOCKER_INFLUXDB_INIT_ADMIN_TOKEN: libredb-influxdb2-operator-token
      # A server otherwise reports to telemetry.influxdata.com every 8 hours.
      INFLUXD_REPORTING_DISABLED: "true"
    ports:
      - "127.0.0.1:8086:8086"
    healthcheck: *influxdb-ping-health
    <<: *influxdb-limits

  influxdb3:
    image: influxdb:3.12.0-core@sha256:624d69bca6bf6fb174aca5a974e1d96e5c5486994e6ae35bc9b4fe02b9520076
    container_name: libredb-influxdb3
    restart: unless-stopped
    environment: &influxdb3-env
      # The admin token, in the file shape `influxdb3 create token --admin --offline` writes,
      # read by `serve --admin-token-file`. That command mints a random token; this one is the
      # fixed test token, so the seed and the evidence harness read it from this file.
      LIBREDB_INFLUXDB3_TOKEN: apiv3_libredb-influxdb3-admin-token
    entrypoint: &influxdb3-entrypoint
      - bash
      - -c
      - >-
        umask 077 &&
        printf '{"token": "%s", "name": "_admin"}\n' "$$LIBREDB_INFLUXDB3_TOKEN" > /tmp/admin-token.json &&
        exec influxdb3 serve --node-id libredb --object-store file
        --data-dir /home/influxdb3/.influxdb3 --admin-token-file /tmp/admin-token.json
        --disable-telemetry-upload "$$@"
      - influxdb3
    ports:
      - "127.0.0.1:8181:8181"
    healthcheck: &influxdb3-ping-health
      # /ping needs a token on 3.x; the image carries curl.
      test:
        - CMD-SHELL
        - 'curl -sf -o /dev/null -H "Authorization: Bearer $$LIBREDB_INFLUXDB3_TOKEN" http://127.0.0.1:8181/ping'
      start_period: 30s
      start_interval: 1s
      interval: 30s
      timeout: 5s
      retries: 3
    <<: *influxdb-limits

  influxdb3-filelimit:
    # The same server with --query-file-limit 1, so a query over more than one of the Parquet
    # files `seed.sh filelimit` persists meets the file-limit error: 21 timestamps 4 hours
    # apart, each in its own 10-minute gen1 window, persist 21 files (measured 2026-10-04).
    # A snapshot after every WAL file, and after 10 seconds at most, persists the seed within
    # seconds of the write. Profile-gated: only the evidence harness and the preview-window
    # measurement read it.
    image: influxdb:3.12.0-core@sha256:624d69bca6bf6fb174aca5a974e1d96e5c5486994e6ae35bc9b4fe02b9520076
    container_name: libredb-influxdb3-filelimit
    profiles: ["influxdb-filelimit"]
    restart: unless-stopped
    environment: *influxdb3-env
    entrypoint: *influxdb3-entrypoint
    command: ["--query-file-limit", "1", "--wal-files-per-snapshot", "1", "--force-snapshot-max-age", "10s"]
    ports:
      - "127.0.0.1:8182:8181"
    healthcheck: *influxdb3-ping-health
    <<: *influxdb-limits

  influxdb-seed:
    # One-shot seed (docker/influxdb/seed.sh) in the 2.9.1 image, which carries bash, curl and
    # GNU date, so the seed pulls no image of its own. It creates what is missing and leaves
    # what exists: a second run on a seeded server writes nothing.
    image: influxdb:2.9.1@sha256:db0bdab1e5ad5ee899c127b8c13d9c986a3ced78cd9200dd80a1064bf1533b6e
    container_name: libredb-influxdb-seed
    restart: "no"
    depends_on:
      influxdb1:
        condition: service_healthy
      influxdb2:
        condition: service_healthy
      influxdb3:
        condition: service_healthy
    volumes:
      - ./docker/influxdb:/seed:ro
      - influxdb2-read-token:/tokens
    environment:
      INFLUXDB1_URL: http://influxdb1:8086
      INFLUXDB2_URL: http://influxdb2:8086
      INFLUXDB3_URL: http://influxdb3:8181
      # 2.9.1 shows a token's value only when it creates it, so the seed keeps the read-only
      # token here; read it with `docker cp libredb-influxdb-seed:/tokens/influxdb2-read-token -`.
      INFLUXDB2_READ_TOKEN_FILE: /tokens/influxdb2-read-token
    entrypoint: ["bash", "/seed/seed.sh"]
    # The one-shot bound of the Milvus certificate and Qdrant key jobs, shared here: the anchor
    # is named after the vector fixtures that declared it.
    <<: *vector-one-shot-limits

  # ---------------------------------------------------------------------------------------
  # Neo4j (the neo4j provider). One Community server, Bolt for the provider and HTTP for the
  # health probe only. The seed is a graph written for this repository, loaded by hand once the
  # service is healthy; the official Movies graph carries no licence and is not vendored. The
  # graph and the commands are described in docker/neo4j/README.md.
  # ---------------------------------------------------------------------------------------
  neo4j:
    # Pinned to the exact build the provider is verified against, by tag and by digest: the
    # error codes, the value encodings and the captures the provider is tested on are claims
    # about 5.26.31, not about Neo4j in general.
    image: neo4j:5.26.31-community@sha256:d9cfe82983d27f5a75b3aaae8f316d04f9a698a3b7f6103a508f7caf8362f255
    container_name: libredb-neo4j
    restart: unless-stopped
    ports:
      # Loopback only, as the postgres service's. 7687 is Bolt, the provider's transport; 7474
      # is HTTP, kept for the probe and the Browser a developer may open by hand.
      - "127.0.0.1:7687:7687"
      - "127.0.0.1:7474:7474"
    environment:
      # The test credential, as the clickhouse and couchbase services spell theirs. Neo4j
      # refuses a password shorter than 8 characters, which rules out the postgres/postgres form.
      NEO4J_AUTH: neo4j/password123
      # Small enough to sit inside the bound below: heap plus page cache plus the JVM's own.
      NEO4J_server_memory_heap_max__size: 512m
      NEO4J_server_memory_pagecache_size: 128m
      # No usage report to Neo4j from a test fixture.
      NEO4J_server_bolt_telemetry_enabled: "false"
    # No data volume: removing the container resets the fixture.
    healthcheck:
      # The HTTP discovery document, answered once the server accepts connections. The image
      # ships wget; cypher-shell would start a JVM per probe.
      test: ["CMD-SHELL", "wget -q -O - http://localhost:7474/ || exit 1"]
      start_period: 60s
      start_interval: 2s
      interval: 60s
      timeout: 5s
      retries: 3
    # Bounded as the etcd and Kafka fixtures are; no swap past it.
    deploy:
      resources:
        limits:
          cpus: "1"
          memory: 1G
    memswap_limit: 1G

  # ==========================================================================
  # Wire-compatible engines (issue #424, Phase 0)
  #
  # These have no provider of their own: each speaks the wire protocol of a driver
  # we already ship, and the entries below are the instances a gate-4 probe
  # actually ran against. They exist so the compatibility claims in
  # `src/lib/db/compatibility.ts` can be re-measured rather than trusted.
  #
  # All of them carry `profiles: ["compat"]`, so a plain `docker compose up` still
  # starts only the shipped engines. Bring them up deliberately:
  #   docker compose -f database-compose.yml --profile compat up -d
  # ==========================================================================

  # -- PostgreSQL wire ------------------------------------------------------

  citus:
    image: citusdata/citus:latest
    container_name: libredb-citus
    profiles: ["compat"]
    environment:
      POSTGRES_PASSWORD: postgres
    ports:
      - "5435:5432"

  # network_mode: host is not a shortcut here. CockroachDB 26.x refuses an insecure
  # cluster whose --listen-addr is not 127.0.0.1/localhost, and a loopback bind
  # inside the container namespace cannot be published with -p. Host networking is
  # the only way to reach an insecure single node; the alternative is a secure
  # cluster with --accept-sql-without-tls.
  #
  # LINUX ONLY. Docker Desktop (macOS, Windows) runs containers inside a VM, where
  # `host` is the VM rather than your machine, so 127.0.0.1:26257 will not answer
  # there. On those platforms run a secure cluster with --accept-sql-without-tls and
  # a normal port mapping instead. The probe behind this entry ran on Linux.
  cockroachdb:
    image: cockroachdb/cockroach:latest
    container_name: libredb-cockroachdb
    profiles: ["compat"]
    network_mode: host
    command: start-single-node --insecure --listen-addr=localhost:26257 --http-addr=localhost:18080
    healthcheck:
      test: ["CMD", "./cockroach", "sql", "--insecure", "--host=127.0.0.1:26257", "-e", "SELECT 1"]
      interval: 10s
      timeout: 5s
      retries: 12

  materialize:
    image: materialize/materialized:latest
    container_name: libredb-materialize
    profiles: ["compat"]
    ports:
      - "6875:6875"

  # QuestDB speaks the PostgreSQL wire protocol on 8812 and its own HTTP API on 9000.
  #
  # This service exists to reproduce a REFUSAL, not a working connection: QuestDB was probed
  # on 2026-08-26 and earns no registry row, because the editor cannot run anything there -
  # every run with a `queryId` is preceded by `SELECT pg_backend_pid()`, which QuestDB does
  # not have. It stays here so that finding can be re-measured rather than trusted; see
  # `docs/providers/README.md`, "Measured, and refused a row".
  #
  # The HTTP port is published because the fixture recipe seeds through it: QuestDB has no
  # `psql`-friendly bulk insert, and `long_sequence()` over /exec is the documented way.
  #
  # PINNED to 10.0.1, which is what the 2026-08-26 probe measured. `:latest` moved during
  # that probe run - the tag served 10.0.1 while `version()` still answers PostgreSQL 12.3,
  # so a rolling tag would change the engine under a version string that never moves.
  questdb:
    image: questdb/questdb:10.0.1
    container_name: libredb-questdb
    profiles: ["compat"]
    ports:
      - "18812:8812"
      - "19000:9000"

  risingwave:
    image: risingwavelabs/risingwave:latest
    container_name: libredb-risingwave
    profiles: ["compat"]
    command: single_node
    ports:
      - "4566:4566"

  # TimescaleDB is an extension, not a fork: the server is a stock PostgreSQL 17 and
  # `SELECT version()` says so. The extension version comes from pg_extension, which
  # is why the probed version records both.
  timescaledb:
    image: timescale/timescaledb:latest-pg17
    container_name: libredb-timescaledb
    profiles: ["compat"]
    environment:
      POSTGRES_PASSWORD: probe
      POSTGRES_DB: probe
    ports:
      - "15432:5432"

  # Percona Distribution for PostgreSQL. Same reasoning as `percona-mysql` above, and the
  # one measured difference is the opposite of that one's: this build DOES put its own name
  # in `version()`, so the product displays it.
  percona-postgresql:
    image: percona/percona-distribution-postgresql:18.6
    container_name: libredb-percona-postgresql
    profiles: ["compat"]
    environment:
      POSTGRES_PASSWORD: "Probe123pass!"
      POSTGRES_DB: probe
    ports:
      - "15440:5432"

  # ParadeDB: PostgreSQL plus nine extensions (pg_search, pgvector, PostGIS, pg_ivm and the
  # rest). PINNED to a RELEASE tag rather than `latest`, because `version()` names only
  # PostgreSQL here - the tag is the only record of which ParadeDB was measured.
  #
  # Expect a crowded object browser: 41 objects for 2 user tables on a fresh database, and
  # agent plan mode fails on it (B52). That is the finding, not a misconfiguration.
  paradedb:
    image: paradedb/paradedb:0.25.4
    container_name: libredb-paradedb
    profiles: ["compat"]
    environment:
      POSTGRES_PASSWORD: "Probe123pass!"
      POSTGRES_DB: probe
    ports:
      - "15441:5432"

  # OrioleDB: a storage-engine extension on PostgreSQL, and the tables a fresh database
  # creates already use it (`default_table_access_method` is `orioledb`) - verified, since a
  # probe against heap tables would measure PostgreSQL and not OrioleDB.
  #
  # The tag is a DATED NIGHTLY on purpose: the project publishes no release tags at all, so
  # `pg18-nightly-ubuntu` moves under you. This is the build the 2026-08-27 probe measured.
  orioledb:
    image: orioledb/orioledb:pg18-nightly-20260824-cc35a80-ubuntu
    container_name: libredb-orioledb
    profiles: ["compat"]
    environment:
      POSTGRES_PASSWORD: "Probe123pass!"
      POSTGRES_DB: probe
    ports:
      - "15442:5432"

  # `yugabyted` is the single-node launcher: it starts the master and the tserver in
  # one container, and --background=false keeps it in the foreground so Docker owns
  # the process and the container does not exit immediately. YSQL listens on 5433,
  # NOT the PostgreSQL default 5432 - connecting to 5432 here reaches nothing. Sign
  # in as user `yugabyte`, database `yugabyte`, no password.
  yugabytedb:
    image: yugabytedb/yugabyte:2.25.2.0-b359
    container_name: libredb-yugabytedb
    profiles: ["compat"]
    command: bin/yugabyted start --background=false
    ports:
      - "15433:5433"

  # THIRD-PARTY IMAGE, stated because it is unusual here: Apache publishes only
  # BUILD images for Cloudberry - you compile the server inside them - so the
  # project itself ships nothing runnable, and this is a community image. The probe
  # behind this entry ran on it; nothing is claimed about an Apache-built server.
  #
  # Boot takes about two minutes before Postgres answers: the entrypoint initialises
  # a coordinator and its segments first. `shm_size: 1gb` is what the probe ran with,
  # the segment processes communicating through shared memory. Sign in as user
  # `gpadmin`, password `probe`, database `probe`.
  #
  # `gpadmin` is a superuser, and the agent's execution profile refuses it as too
  # broad, so an agent run here needs a least-privilege role created by hand - and
  # even then the grounding read is refused, because gp_toolkit alone answers more
  # rows than its budget allows (B52).
  cloudberry:
    image: woblerr/cloudberry:2.1.0-incubating
    container_name: libredb-cloudberry
    profiles: ["compat"]
    shm_size: 1gb
    environment:
      CLOUDBERRY_PASSWORD: probe
      CLOUDBERRY_DATABASE_NAME: probe
    ports:
      - "15435:5432"

  # AlloyDB Omni is Google's downloadable AlloyDB, and it needs nothing unusual to
  # run: `POSTGRES_PASSWORD` is the only variable the probe behind this entry set.
  # No licence key, no `ulimit` change, no memory floor, and no `shm_size` - unlike
  # the cloudberry service above, which needs one. Sign in as user `postgres` with
  # the password below, database `postgres` (the entrypoint's default when
  # POSTGRES_DB is unset).
  #
  # The tag is pinned, and the pin is free: the registry carries 87 tags including
  # 15.x, 16.x, 17.5.0 and 17.7.0, and 17.9.0's digest is currently the same digest
  # `:latest` serves. Only 17.9.0 was probed.
  #
  # `SELECT version()` here says "PostgreSQL 17.9" and nothing else - the string
  # names AlloyDB nowhere - so the overview cannot be told apart from a stock
  # PostgreSQL 17. Confirm which server you are on from the `alloydb.*` settings, or
  # from this tag.
  #
  # Two things a probe here should expect. The columnar engine is OFF: switching it
  # on takes ALTER SYSTEM plus a container restart, not a reload. And an agent run
  # needs a least-privilege role created by hand, because the image's own `postgres`
  # superuser is refused as too broad - after which the grounding read is refused
  # anyway, at 536 rows against a 200-row budget, most of them the extension views
  # this image installs into `public` itself (B52).
  alloydb:
    image: google/alloydbomni:17.9.0
    container_name: libredb-alloydb
    profiles: ["compat"]
    environment:
      POSTGRES_PASSWORD: probe
    ports:
      - "15436:5432"

  # -- MySQL wire ----------------------------------------------------------

  mariadb:
    image: mariadb:latest
    container_name: libredb-mariadb
    profiles: ["compat"]
    environment:
      MARIADB_ROOT_PASSWORD: root
      MARIADB_DATABASE: probe
    ports:
      - "3307:3306"
    volumes:
      # The MariaDB half of the object-browser fixture (#789), and it is a SEPARATE file
      # from the MySQL one on purpose: this provider's `objectKinds` is resolved from the
      # server's own version string, and MariaDB declares `package` and `sequence`, which
      # MySQL does not have at all. See docs/providers/mysql.md.
      - ./docker/mariadb-init:/docker-entrypoint-initdb.d:ro
    healthcheck:
      test: ["CMD", "mariadb-admin", "ping", "-uroot", "-proot", "--silent"]
      interval: 5s
      timeout: 5s
      retries: 20

  # Percona Server for MySQL, a drop-in build of MySQL. Nothing here is Percona-specific:
  # the point of the entry is that the probe ran against a real one rather than assuming a
  # drop-in behaves like the thing it drops into.
  #
  # PINNED to 8.4: `version()` answers a bare 8.4.11-11 there and the product name is only in
  # `@@version_comment`, so the tag is the only durable record of which build was measured.
  percona-mysql:
    image: percona/percona-server:8.4
    container_name: libredb-percona-mysql
    profiles: ["compat"]
    environment:
      MYSQL_ROOT_PASSWORD: "Probe123pass!"
    ports:
      - "13307:3306"

  # Databend serves a MySQL wire handler on 3307 (not 3306) beside its own HTTP API on 8000.
  # Connect as `mysql` on the published 13308.
  #
  # It implements no prepared statement (`Prepare is not support in Databend`), so the provider
  # binds parameterised reads client-side there, and that is what this service reproduces. Its
  # row is `partial`: the overview, health and session panels have no source on the engine.
  #
  # PINNED to a patch release rather than `nightly`, which is what the tag list mostly holds.
  databend:
    image: datafuselabs/databend:v1.2.925-patch-11
    container_name: libredb-databend
    profiles: ["compat"]
    environment:
      QUERY_DEFAULT_USER: root
      QUERY_DEFAULT_PASSWORD: "Probe123pass!"
    ports:
      - "13308:3307"
      - "18000:8000"

  # TiDB needs no PD and no TiKV to run here: --store=unistore is its embedded
  # single-node storage engine, so this is one container like every other entry, and
  # an empty --path keeps that store in memory. TiDB speaks the MySQL protocol on
  # 4000, not 3306. Sign in as user `root`, no password. The probe behind this entry
  # ran on unistore only, never against a PD + TiKV cluster.
  tidb:
    image: pingcap/tidb:v8.5.1
    container_name: libredb-tidb
    profiles: ["compat"]
    command: ["--store=unistore", "--path=", "--host=0.0.0.0"]
    ports:
      - "14000:4000"

  # allin1 is StarRocks in one container - the frontend and the backend together -
  # and it is the form the probe behind this entry ran against. StarRocks speaks the
  # MySQL protocol on 9030, not 3306. Sign in as user `root`, no password.
  starrocks:
    image: starrocks/allin1-ubuntu:3.3-latest
    container_name: libredb-starrocks
    profiles: ["compat"]
    ports:
      - "19030:9030"

  # Apache Doris, the engine StarRocks above was forked from. The all-in-one image is
  # an FE and a BE in one container and needs no cluster, so this entry is a single
  # service like the StarRocks one.
  #
  # The tag is PINNED. `all-in-one-4.1.3` is what the 2026-08-26 probe measured, and
  # Doris publishes its real build only in `@@version_comment` - `version()` answers a
  # fictitious 5.7.99 - so a rolling tag would silently move the version this fixture
  # reproduces while every panel kept displaying the same 5.7.99.
  #
  # `nofile` is raised for the same reason the OceanBase entry raises it: the BE opens
  # a file handle per tablet and the container default of 1024 is not enough for a
  # loaded table.
  #
  # `root` has no password on a fresh image. Set one before probing - the fixture
  # recipe in docs/providers/README.md does - because the connection dialog treats an
  # empty password as a field the user has not filled in yet.
  doris:
    image: apache/doris:all-in-one-4.1.3
    container_name: libredb-doris
    profiles: ["compat"]
    ulimits:
      nofile:
        soft: 65536
        hard: 65536
    ports:
      - "19035:9030"
      - "18035:8030"

  # vttestserver is Vitess in one container: it brings up the topology, a vtctld, a
  # vtgate and a mysqld for the keyspace named in KEYSPACES, so this entry needs no
  # cluster of its own.
  #
  # The tag is PINNED deliberately. The rolling `:mysql80` tag serves a
  # 25.0.0-SNAPSHOT built from main - not a release, and not reproducible - so the
  # probe behind this entry ran on v24.0.2 and this file names it.
  #
  # PORT is the base of the range vttestserver allocates, and vtgate's MySQL port is
  # 33577, which is what this entry publishes; 3306 reaches nothing. Sign in as user
  # `root`, no password, database `probe`. NUM_SHARDS=1 is the shape that was probed:
  # a sharded keyspace was not.
  #
  # This fixture cannot be used to test a permission error. vttestserver accepts any
  # username with any password and grants it full rights, and CREATE USER is a vtgate
  # parse error, so no restricted role can be made here. That is the fixture, not
  # Vitess.
  vitess:
    image: vitess/vttestserver:v24.0.2-mysql80
    container_name: libredb-vitess
    profiles: ["compat"]
    environment:
      PORT: 33574
      KEYSPACES: probe
      NUM_SHARDS: 1
      MYSQL_BIND_HOST: 0.0.0.0
    ports:
      - "33577:33577"

  # THE DOCUMENTED RUN COMMAND FOR THIS IMAGE FAILS, and the `ulimits` block below is
  # the whole reason this entry is longer than the others. The container's default
  # soft `nofile` is 1024 and OceanBase's own deployer requires at least 20000, so
  # without the override the boot dies after about 12 seconds with `OBD-1007` and no
  # server ever listens. Keep the ulimit, or the next person repeats that failure.
  #
  # The memory floor is real too: the project documents 2 cores and 8 GB as the
  # minimum, and the probe behind this entry ran with a 12 GB limit. `MODE=mini` is
  # what makes a single container viable at all - it is the small-footprint
  # deployment, and it creates ONE user tenant named `test`.
  #
  # So sign in as `root@test`, no password, database `test` - the BUSINESS tenant,
  # not `sys`. Connecting to the `sys` tenant instead shows nine databases including
  # Oracle-mode artifacts (LBACSYS, ORAAUDITOR, SYS, ocs, sys_external_tbs) that a
  # user tenant does not have. OceanBase speaks the MySQL protocol on 2881, not 3306.
  # Wait for `boot success!` in the log before connecting; the container is up long
  # before the server is.
  #
  # The tag is pinned, and the pin is free: 4.4.2-lts had the same digest as
  # `:latest` at probe time. 507 MB compressed, 1.5 GB on disk.
  #
  # A probe here should expect no performance_schema database at all - health is the
  # one surface that fails outright (ERROR 1049) - and every size reading 0 B,
  # because information_schema.TABLES reports DATA_LENGTH 0 and INDEX_LENGTH 0. Row
  # counts are correct after `ANALYZE TABLE t`, which must be the MySQL-mode form:
  # the Oracle-mode `ANALYZE TABLE t COMPUTE STATISTICS` is rejected with ERROR 1235.
  oceanbase:
    image: oceanbase/oceanbase-ce:4.4.2-lts
    container_name: libredb-oceanbase
    profiles: ["compat"]
    environment:
      MODE: mini
    ulimits:
      nofile:
        soft: 655350
        hard: 655350
    ports:
      - "12881:2881"

  # NO LICENCE KEY IS NEEDED, which is worth stating because issue #424 recorded the
  # opposite as the reason this engine went unprobed. The dev image self-licenses
  # with `ROOT_PASSWORD` as the only variable set: its log records
  # `SetLicenseV4: Expiration = unlimited` and `Options = 72 (Developer Image
  # edition)`, and every query in the probe behind this entry ran. There is one
  # harmless WARN about exceeding a 1-unit capacity licence.
  #
  # SingleStore speaks the MySQL protocol on 3306, which the always-on `mysql`
  # service already claims on the host, hence 13306 here. 8080 is its own Studio UI,
  # published on 18081 for the same reason. Sign in as user `root` with the password
  # below, database `probe` after you create one. No `ulimit` change is needed here,
  # unlike the oceanbase service above; the probe behind this entry ran the container
  # with `--cpus=8`.
  #
  # A probe here should expect five surfaces to fail on ONE cause that is ours, not
  # SingleStore's: the provider sends every statement through mysql2's binary
  # prepared protocol, and SingleStore answers `This command is not supported in the
  # prepared statement protocol yet` to the parameterless SHOW and EXPLAIN
  # statements that Test Connection, health, the overview and the monitoring
  # dashboard need (D8 in docs/BACKLOG.md). Row counts and sizes read 0 for a
  # populated table because information_schema.TABLES is left zeroed, and `ANALYZE`
  # does not change it.
  singlestore:
    image: ghcr.io/singlestore-labs/singlestoredb-dev:0.2.82
    container_name: libredb-singlestore
    profiles: ["compat"]
    environment:
      ROOT_PASSWORD: "Probe123pass!"
    ports:
      - "13306:3306"
      - "18081:8080"

  # -- Redis wire ----------------------------------------------------------

  valkey:
    image: valkey/valkey:latest
    container_name: libredb-valkey
    profiles: ["compat"]
    ports:
      - "6380:6379"
    healthcheck:
      test: ["CMD", "valkey-cli", "ping"]
      interval: 5s
      timeout: 3s
      retries: 10

  dragonfly:
    image: docker.dragonflydb.io/dragonflydb/dragonfly:latest
    container_name: libredb-dragonfly
    profiles: ["compat"]
    ulimits:
      memlock: -1
    ports:
      - "6381:6379"
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 5s
      timeout: 3s
      retries: 10

  keydb:
    image: eqalpha/keydb:latest
    container_name: libredb-keydb
    profiles: ["compat"]
    ports:
      - "6382:6379"
    healthcheck:
      test: ["CMD", "keydb-cli", "ping"]
      interval: 5s
      timeout: 3s
      retries: 10

  # Microsoft Garnet, the fourth RESP relative. Single container, no configuration, and it
  # needs no password - it starts with none, like the `redis` service above.
  #
  # PINNED to 2.1.5: Garnet publishes its own version (`garnet_version` in INFO), as Valkey
  # and DragonflyDB do, so the tag and the caveat about which version the product displays
  # have to stay in step.
  #
  # No volume, deliberately: Garnet holds everything in memory here and a restart empties it
  # (measured - `dbsize` 71 before a `docker stop`, 0 after), so re-run the key seeding from
  # docs/providers/README.md rather than expecting the fixture to survive.
  garnet:
    image: ghcr.io/microsoft/garnet:2.1.5
    container_name: libredb-garnet
    profiles: ["compat"]
    ports:
      - "16380:6379"

  # -- MongoDB wire --------------------------------------------------------

  # FerretDB is a proxy, not a database: it needs its own PostgreSQL-with-
  # DocumentDB backend, which is why it is the only two-service entry here. Sign in
  # with the BACKEND's PostgreSQL credentials - FerretDB rejects authMechanism=PLAIN.
  ferretdb-backend:
    image: ghcr.io/ferretdb/postgres-documentdb:latest
    container_name: libredb-ferretdb-backend
    profiles: ["compat"]
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
      POSTGRES_DB: postgres
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "postgres"]
      interval: 5s
      timeout: 5s
      retries: 20

  ferretdb:
    image: ghcr.io/ferretdb/ferretdb:latest
    container_name: libredb-ferretdb
    profiles: ["compat"]
    depends_on:
      ferretdb-backend:
        condition: service_healthy
    environment:
      FERRETDB_POSTGRESQL_URL: postgres://postgres:postgres@ferretdb-backend:5432/postgres
    ports:
      - "27018:27017"

  # -- CQL wire ------------------------------------------------------------

  # Pinned to the exact build the Phase 4 probe ran against, the same rule the
  # cassandra service above follows: `system.local.release_version` here is `3.0.8`,
  # a Cassandra compatibility number, and the real build is only in
  # `system.versions` (`2026.2.4-0.20260810.e54224b8cebb`).
  #
  # The compatibility row this reproduces covers TWO lines, and only one of them is
  # here: `scylladb/scylla:2025.1` (`2025.1.14-0.20260612.103b84070f3b`) was probed in
  # the same pass and behaved identically on every surface. To re-measure that half,
  # run the same image tag by hand on a free host port - `9242` was the probe's - with
  # these same flags; a second service would publish a name the docs table does not.
  #
  # The command flags are the sizing that was measured to work, not a
  # conservative guess. `--memory 2G` inside a 3 GiB container is REFUSED outright
  # with `insufficient physical memory: needed 2095054848 available 1488977920`;
  # `--smp 1 --memory 1G --overprovisioned 1 --developer-mode 1` came up in well
  # under a minute, against ~206 seconds for the cassandra image. `mem_limit: 4g`
  # is the container the working combination was measured in, pinned for the same
  # reason the cassandra service pins its own.
  #
  # The other thing a probe here must know: the 2026.2 line REFUSES SimpleStrategy
  # (`SimpleStrategy doesn't support tablet replication`), so a keyspace has to be
  # created with `{'class':'NetworkTopologyStrategy','datacenter1':1}` and the
  # recipe in docs/providers/cassandra.md does not run unchanged.
  #
  # 9142 on the host because the cassandra service already publishes 9042; the
  # native port is 9042 in the container on both, so this is a collision on THIS
  # machine, not a fact about the product. No auth, data centre `datacenter1`.
  #
  # No healthcheck: none was measured on this image, and a wrong one would be worse
  # than none - see the cassandra service above, where the readiness condition that
  # actually matters was found by timing a cold start.
  scylla:
    image: scylladb/scylla:2026.2.4
    container_name: libredb-scylla
    profiles: ["compat"]
    command: --smp 1 --memory 1G --overprovisioned 1 --developer-mode 1
    ports:
      - "9142:9042"
    mem_limit: 4g

  # -- Prometheus HTTP API -------------------------------------------------

  # VictoriaMetrics single-node, the wire-compatible relative of the `prometheus` provider
  # (#1085 section 7): the Prometheus querying API on 8428, evaluated by MetricsQL, its own
  # query language. The relative is claimed for PromQL only.
  #
  # PINNED to v1.152.0, the build the gate-4 probe ran against. The v1.136.x LTS line is not
  # published as an open-source image (#1085 section 7: `v1.136.15` answers 404 on Docker
  # Hub), so there is no LTS tag to pin instead.
  #
  # It scrapes the targets of the `prometheus` service through the compose network
  # (docker/victoriametrics/scrape.yml), so the two servers can be asked the same questions
  # side by side, and it waits for that service to be healthy because its main target is that
  # service. Single-node VictoriaMetrics evaluates no rules, so every metric the rule files in
  # docker/prometheus/rules/ produce exists on 9090 only.
  #
  # No healthcheck, deliberately: which health path this build answers is one of the
  # questions the probe asks, so a check here would presuppose the answer.
  victoriametrics:
    image: victoriametrics/victoria-metrics:v1.152.0
    container_name: libredb-victoriametrics
    profiles: ["compat"]
    command:
      - "-promscrape.config=/etc/victoriametrics/scrape.yml"
    volumes:
      - ./docker/victoriametrics:/etc/victoriametrics:ro
    ports:
      - "8428:8428"
    depends_on:
      prometheus:
        condition: service_healthy

  # -- Kafka wire -------------------------------------------------------------

  # Redpanda, the wire-compatible relative of the `kafka` provider (#1088 section 8), seeded
  # by the same two scripts as the `kafka` service:
  #   docker run --rm --network host -v "$PWD/docker/kafka/seed.sh:/seed.sh:ro" \
  #     --entrypoint bash apache/kafka:4.3.1 /seed.sh localhost:29092
  #   bun docker/kafka/seed-binary.ts localhost:29092
  #
  # PINNED to v26.2.2, the latest GitHub release on 2026-09-23. Docker Hub also carries
  # v26.2.3 with no matching tag in redpanda-data/redpanda, so it is not treated as released.
  # No healthcheck: which surfaces this build answers is what the probe asks.
  redpanda:
    image: redpandadata/redpanda:v26.2.2
    container_name: libredb-redpanda
    profiles: ["compat"]
    restart: unless-stopped
    command:
      - redpanda
      - start
      - --mode=dev-container
      - --smp=1
      # Seastar's own memory, fixed rather than sized from the container at start; the
      # seeded fixture peaked at 219 MiB of the container.
      - --memory=1G
      - --kafka-addr=internal://0.0.0.0:9092,external://0.0.0.0:29092
      - --advertise-kafka-addr=internal://redpanda:9092,external://localhost:29092
    ports:
      - "127.0.0.1:29092:29092"
    # 512M above the 1G Seastar is given, for what it allocates outside that; one core for
    # --smp=1 (measured peak 0.19 of one core); no swap past it.
    deploy:
      resources:
        limits:
          cpus: "1"
          memory: 1536M
    memswap_limit: 1536M

volumes:
  # Named volumes for Druid, for the certificates of kafka-auth and the etcd auth fixtures, and
  # for the vector fixtures. Druid is the one service here whose processes must share state
  # (deep storage) and whose task history is worth surviving a restart; kafka-auth-certs hands
  # the generated CA and broker certificate from the one-shot kafka-auth-certs service to the
  # broker, and etcd-auth-certs the generated certificates and passwords from etcd-auth-certs to
  # the two etcd auth servers and their init one-shots. Each Milvus server keeps its data in a
  # volume of its own, because the image runs as uid 999 and a bind mount crashed it;
  # milvus-certs and milvus-credentials hold the generated certificates and the seeded users'
  # passwords, and qdrant-keys the generated Qdrant keys, local.yaml files and certificates.
  # influxdb2-read-token keeps the InfluxDB 2.x read-only token influxdb-seed created, whose
  # value the server shows only once. oxia-auth-material carries the generated certificates, JWT
  # keys and tokens from oxia-auth-certs to the Oxia auth server. Everything else uses the image's
  # own anonymous volumes.
  #
  # druid_shared is the deep-storage + indexing-log volume, mounted by the three processes
  # that write or read segments. A `down -v` resets the cluster to empty.
  druid_shared: {}
  druid_coordinator_var: {}
  druid_historical_var: {}
  druid_middlemanager_var: {}
  druid_broker_var: {}
  druid_router_var: {}
  kafka-auth-certs: {}
  etcd-auth-certs: {}
  oxia-auth-material: {}
  milvus-data: {}
  milvus-tls-data: {}
  milvus-mtls-data: {}
  milvus-certs: {}
  milvus-credentials: {}
  qdrant-keys: {}
  influxdb2-read-token: {}