---
id: 4bb882a6-1ef9-4ec4-873d-816881f6670b
type: solution
title: "Paper Dynasty: Database sync workflow for prod to dev"
tags: [paper-dynasty, postgresql, database, sync, workflow, automation]
importance: 0.8
confidence: 0.8
created: "2026-02-03T20:26:11.869126+00:00"
updated: "2026-02-03T20:26:11.869126+00:00"
relations:
  - target: b5f56d48-32b5-46b9-8609-e20a4aa3ac28
    type: BUILDS_ON
    direction: outgoing
    strength: 0.5
  - target: a918ab78-70dc-49bf-bcb8-e98e6bdd624e
    type: RELATED_TO
    direction: outgoing
    strength: 0.5
---

Created automated workflow to sync production PostgreSQL database (akamai) to dev environment (pd-database).

FILES CREATED:
- ~/.claude/skills/paper-dynasty/scripts/sync_prod_to_dev.sh - Main automation script
- ~/.claude/skills/paper-dynasty/workflows/database-sync.md - Complete documentation
- Updated ~/.claude/skills/paper-dynasty/SKILL.md - Added workflow to skill triggers

SCRIPT FEATURES:
- Pre-flight connectivity checks to both databases
- Database statistics before/after (size, table count)
- Automatic timestamped backups to ~/.paper-dynasty/db-backups/
- Safety confirmation prompt (or --yes flag to skip)
- Dry-run mode (--dry-run) for preview
- No-backup mode (--no-backup) for speed
- Colored output for readability
- Error handling with automatic cleanup

DATABASE DETAILS:
- Production: akamai, container sba_postgres, database pd_master, user pd_admin
- Dev: pd-database (10.10.0.42), container sba_postgres, database paperdynasty_dev, user sba_admin
- Both are PostgreSQL (migrated from SQLite in Jan 2026)

USAGE:
~/.claude/skills/paper-dynasty/scripts/sync_prod_to_dev.sh --yes
# Or via skill: /paper-dynasty sync prod to dev

TESTED RESULTS:
- Production: 151 MB, 29 tables, 68,191 cards, 105 teams
- Dev after sync: 61 MB, 37 tables, 68,191 cards, 105 teams
- Backup created: 289K SQL dump
- Sync time: ~1-2 minutes

KNOWN ISSUES:
- Role ownership errors at end (pd_admin role doesn't exist on dev) - harmless, data sync succeeds
- The dump includes role OWNER statements that fail but don't affect data integrity

USE CASES:
- Testing PostgreSQL migration changes with real production data
- Debugging production issues locally
- QA testing with production-sized datasets
- Setting up new dev environments