12.1.2.3 Dev Database Service

A dev database service runs a containerized database instance specifically for local development, configured with convenience-oriented settings — exposed ports, simple credentials, optional seed data — that prioritize ease of local use over the security and durability concerns appropriate to a production deployment.

A Typical Dev Database Configuration

The development database is configured for easy local access and quick iteration, rather than production-grade security.

services:
  db:
    image: postgres:16
    ports:
      - "5432:5432"
    environment:
      - POSTGRES_USER=devuser
      - POSTGRES_PASSWORD=devpassword
      - POSTGRES_DB=app_dev
    volumes:
      - dev-db-data:/var/lib/postgresql/data
      - ./db/seed:/docker-entrypoint-initdb.d

Exposing the database's port directly, and using a simple, clearly non-production credential, reflects priorities appropriate specifically to local development.

Why Exposing the Port Directly Is Reasonable in This Context

Unlike a production database, which generally shouldn't expose its port directly to anything outside its own application's network, a local development database's directly exposed port is convenient for a developer wanting to connect with their own preferred database client tool.

psql -h localhost -U devuser -d app_dev

Why Simple Credentials Are Acceptable Here but Not in Production

A development database's credentials, while still not something to be careless about, don't carry the same consequences a leaked production credential would, since this database holds no genuinely sensitive, real user data.

POSTGRES_PASSWORD=devpassword

Including Seed Data for a Realistic Starting State

Automatically running seed scripts the first time the database initializes provides developers with realistic, useful starting data without manual setup.

INSERT INTO users (name, email) VALUES ('Test User', 'test@example.com');

Why a Dev Database Service Configuration Matters

Configuring a development database specifically for local convenience — easy access, simple credentials, helpful seed data — while maintaining a clear, deliberate distinction from production database configuration, supports an efficient development workflow without carrying production security expectations into a context where they're not actually needed.