Adding a real database

BenchKit uses SQLite by default so that it runs with no setup at all. SQLite runs inside the PHP process, which means it has no connection cost and none of the indexing and contention behavior you get from a database server. If you want numbers that reflect how your application talks to a real database, use Laravel's native database drivers to point BenchKit at MySQL, MariaDB, or Postgres.

The two files

Put both files in the same directory. Compose reads .env on its own, so you write each value once and it reaches both containers:

• .env holds the credentials.
• docker-compose.yml hands them to BenchKit as Laravel's DB_* variables, and to the database as the variables its own image expects.

Pick your engine and copy both files.

# BenchKit reads these as Laravel's database config.
# DB_HOST is the service name below, not localhost.
DB_CONNECTION=mysql
DB_HOST=mysql
DB_PORT=3306
DB_DATABASE=benchkit
DB_USERNAME=benchkit
DB_PASSWORD=benchkit_secret

# Only the database container uses this one.
DB_ROOT_PASSWORD=root_secret

# BenchKit reads these as Laravel's database config.
# DB_HOST is the service name below, not localhost.
DB_CONNECTION=mariadb
DB_HOST=mariadb
DB_PORT=3306
DB_DATABASE=benchkit
DB_USERNAME=benchkit
DB_PASSWORD=benchkit_secret

# Only the database container uses this one.
DB_ROOT_PASSWORD=root_secret

# BenchKit reads these as Laravel's database config.
# DB_HOST is the service name below, not localhost.
DB_CONNECTION=pgsql
DB_HOST=postgres
DB_PORT=5432
DB_DATABASE=benchkit
DB_USERNAME=benchkit
DB_PASSWORD=benchkit_secret

Then bring both containers up:

docker compose up -d

The healthcheck on depends_on is what keeps your first run honest. Database images accept connections shortly before they are ready to serve them well, and a benchmark that starts in that window measures the warmup rather than the database.

On a host without Docker

If you are running from source, there is no compose file involved. Set the same DB_* variables however your platform manages environment variables, and point them at a database it can reach.

There is no migration step

BenchKit creates the tables it benchmarks when it needs them, and drops them afterwards. You do not run artisan migrate and there is no seeder to run. Point BenchKit at a database it can reach, and the database route and the PHP stage use it on the next run.