Section 05 · Database & Data

Database & Connections

Database configuration, migrations, users, and access controls

9 items 6 critical 3 recommended

Verification guide for database configuration, migrations, users, and access controls.

The Goal: Hardened Data Layer

The database should be configured for production load, protected by least-privilege access, and impossible to accidentally destroy. Migrations should be tested before they touch production.

  • Pooled — explicit connection limits and timeouts configured
  • Tested — migrations verified in CI against ephemeral databases
  • Least-privilege — app user cannot DROP, read-only user available
  • Restricted — admin credentials limited to 1-2 critical personnel
  • Documented — Redis critical data and admin tools properly protected

Before You Start

  1. Confirm you're in the target repository's root directory
  2. Have database credentials or read-only access available for manual checks
  3. Know your database type (PostgreSQL, MySQL, etc.) for correct commands
  4. Have access to CI configuration (GitHub Actions)
  5. Have the user available for manual verification questions (DB-004, DB-005, DB-008, DB-009)

general

DB-001
Connection pooling and optimization configured critical

Verify Prisma connection pool is explicitly configured with pool size, connection timeout, and idle timeout settings.

“What happens to your DB when traffic spikes unexpectedly?”

DB-002
CI verifies migrations on ephemeral test DB critical

CI pipeline must apply migrations to a Docker-based ephemeral test database, not just dry-run or status checks.

“Migrations tested against a real DB, or just hope they work?”

DB-003
AI-assisted migration review with human override recommended

Migrations reviewed for risky patterns (DROP, ALTER COLUMN, DELETE, etc.) with automated flagging and required human approval before merge.

“Who caught the last DROP COLUMN before it hit production?”

DB-004
Database users documented (including read-only user) critical

All database users documented with purpose and permissions. Must include a read-only user for safe debugging/reporting.

“How many DB users exist, and do you know what each one can do?”

DB-005
App user cannot DROP DATABASE critical

Application database user must not have DROP privilege. Verify via SHOW GRANTS output.

“Could a SQL injection bug wipe your entire database?”

DB-006
Soft delete pattern implemented recommended

Data uses soft deletes (deleted_at column) rather than hard deletes. Separate service handles permanent deletion after retention period.

“When a user deletes their account, is it recoverable?”

DB-007
Redis documented if storing critical data recommended

If Redis stores critical data (sessions, queues), connection and usage must be documented. Cache-only usage is acceptable without documentation.

“If Redis restarts, what critical data evaporates with it?”

DB-008
DB admin tools on-demand and Zero Trust protected critical

Database admin tools (phpMyAdmin, Adminer, pgAdmin) must be on-demand only (not always running) and protected behind Cloudflare Zero Trust when active.

“Is phpMyAdmin running 24/7 somewhere, exposed to the internet?”

DB-009
Admin password restricted to critical people critical

Database admin credentials limited to 1-2 critical people (CTO, DevOps lead). Stored in secret manager, not shared broadly or in plain text.

“Who on your team could drop the production database right now?”