Running databases in Docker

Running databases in Docker Every engine prorm supports can be run locally in a container, which is how the integration tests get their databases. Each guide starts the engine, waits for it correctly (readiness is where most flaky setups go wrong), connects prorm to it, and tears it down. The short path The repository ships a compose file covering the SQL engines the test suite uses: Oracle's image is large and slow (1-2 minutes even with a healthcheck). Skip it with npm run test:db:up:no-oracle. wait in those scripts blocks until every service reports healthy, which is what makes them usable in CI. SQL engines Guide | Engine | Host port | --- | --- | --- | PostgreSQL | PostgreSQL 16 | 5432 | MySQL | MySQL 8.0 | 3306 | MariaDB | MariaDB 11 | 3307 | CockroachDB | CockroachDB | 26257 | ClickHouse | ClickHouse | 8123 (HTTP) | MariaDB deliberately uses 3307 so it can run alongside MySQL. NoSQL stores Guide | Store | Host port | --- | --- | --- | MongoDB | MongoDB — documents | 27017 | Redis | Redis — key/value, also a cache backend | 6379 | Cassandra | Cassandra — wide column | 9042 | Elasticsearch | Elasticsearch — search | 9200 | Neo4j | Neo4j — graph | 7687 (Bolt) | These use the NoSqlStore interface rather than a SQL Dialect — no models, no DDL. See the store index. Runtimes Guide | Runtime | --- | --- | Bun | Bun — uses the built-in bun:sqlite, no native build | Deno | Deno — npm compatibility, explicit permissions | Two things that cause most of the trouble Do not sleep — poll. Every engine opens its port before it can serve queries, so sleep 5 && connect fails intermittently and passes just often enough to look fine. Each guide gives the right readiness check. 127.0.0.1 inside a container is that container. When your application also runs in Docker, put both on a shared network and address the database by its container name. The Bun guide shows the pattern. Related reading Dialects — per-engine SQL behaviour Stores — the NoSQL adapters Connection pooling