---

Title: Safety Levels. Description: Understanding and choosing the right safety level for your migrations.

SAFETY LEVELS

Choose the right balance between safety and optimization for your use case.

💡 Safety levels apply to all CAPYSQUASH tools: Platform (configured in UI), capysquash-cli (via flags), and pgsquash-engine (via API).

OVERVIEW

Four safety levels control how aggressively CAPYSQUASH consolidates your migrations. Each level applies different consolidation rules and balances safety vs optimization.

Principle: Higher safety = fewer consolidation rules = lower risk = less optimization

Important: Safety levels control which consolidation rules are applied. The actual file reduction depends on your migration patterns results may vary based on how your migrations are structured.

COMPARISON TABLE

PARANOID MODE

MAXIMUM SAFETY

Best for:

First-time use Production databases Mission-critical systems When you need proof

Features:

Only safest consolidations (CREATE + ALTER) Requires database validation Column ordering preserved exactly Dead code removal only with DB proof

Example:

capysquash squash migrations/*.sql --safety paranoid

What it does:

• Consolidates CREATE TABLE + ALTER TABLE statements
• Preserves exact column ordering
• Validates against actual database
• Removes only provably dead code

What it doesn't do:

• No DROP/CREATE cycle removal
• No function deduplication
• No RLS policy consolidation
• No aggressive reordering

CONSERVATIVE MODE

PRODUCTION READY

Best for:

Production databases Established projects Risk-averse teams Regular use

Features:

CREATE + ALTER consolidation Column evolution tracking Final column order may differ No database required

Example:

capysquash squash migrations/*.sql --safety conservative

What it does:

• All Paranoid features
• Column ordering may be optimized
• No database validation required
• Faster processing

What it doesn't do:

• No DROP/CREATE cycle removal
• No function deduplication
• No RLS policy consolidation

STANDARD MODE (RECOMMENDED)

BALANCED APPROACH

Best for:

Most use cases Staging environments Regular development Pre-production testing

Features:

All Conservative features Plus DROP/CREATE cycle removal Plus RLS policy consolidation Statement reordering for optimization

Example:

capysquash squash migrations/*.sql --safety standard

What it does:

• All Conservative features
• Removes unnecessary DROP/CREATE cycles
• Consolidates RLS policies
• Optimizes statement ordering

What it doesn't do:

• No function deduplication
• No static dead code removal

AGGRESSIVE MODE

MAXIMUM OPTIMIZATION

Best for:

Development environments Fresh starts Maximum cleanup Non-production use

Features:

All Standard features Plus function deduplication Plus static dead code removal AI-powered semantic analysis

Example:

capysquash squash migrations/*.sql --safety aggressive

What it does:

• All Standard features
• Deduplicates identical functions
• Removes statically-provable dead code
• Uses AI for semantic analysis (optional)

What it doesn't do:

• Not recommended for production without thorough testing

CHOOSING A SAFETY LEVEL

Decision Tree

• Are you squashing for the first time?
• ├─ YES → Start with PARANOID
• └─ NO
• └─ Is this for production?
• ├─ YES → Use CONSERVATIVE
• └─ NO
• └─ Is this a staging/testing environment?
• ├─ YES → Use STANDARD (recommended)
• └─ NO → Use AGGRESSIVE for dev

By Use Case

Individual Developers:

• Local development → AGGRESSIVE or STANDARD
• Pre-production → STANDARD or CONSERVATIVE
• Production → CONSERVATIVE or PARANOID

Teams:

• Development branches → STANDARD
• Staging environment → STANDARD or CONSERVATIVE
• Production → CONSERVATIVE
• First-time use → PARANOID

Agencies:

• Client projects → CONSERVATIVE
• Internal tools → STANDARD
• Legacy cleanup → PARANOID first, then CONSERVATIVE

EXAMPLES

Paranoid Mode Example

# Requires database connection

export PROD_DB_DSN="postgres://user:pass@localhost/db"

# Run with paranoid mode

capysquash squash migrations/*.sql \
  --safety paranoid \
  --output clean/

Conservative Mode Example

# Production-ready without database

capysquash squash migrations/*.sql \
  --safety conservative \
  --output production/

Standard Mode Example

# Recommended for most use cases

capysquash squash migrations/*.sql \
  --safety standard \
  --output optimized/

Aggressive Mode Example

# Maximum cleanup for development

capysquash squash migrations/*.sql \
  --safety aggressive \
  --output dev-clean/

VALIDATION

After squashing, always validate:

capysquash validate migrations/ clean/

This is required for Paranoid mode, but recommended for all levels.

NEXT STEPS

• pgsquash-engine Commands Reference
• Configuration Options
• Docker Validation