postgres-domain-delivery

Review PostgreSQL migrations for production safety with rollback evidence.

Updated Apr 27, 2026
One-click install
npx skills add https://github.com/vTRKA/supervibe --skill postgres-domain-delivery
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: postgres-domain-delivery
Source: https://github.com/vTRKA/supervibe/tree/main/skills/postgres-domain-delivery
Command: npx skills add https://github.com/vTRKA/supervibe --skill postgres-domain-delivery

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

It prevents fragile PostgreSQL schema and migration work by turning changes into production-safe database slices with explicit evidence, rollback discipline, and operational readiness.

Core Features & Use Cases

  • Schema, index, and migration planning with verification evidence: defines data contracts, designs indexes from query shapes, and requires EXPLAIN (ANALYZE, BUFFERS)-style proof for hot-query changes.
  • Online, mixed-version compatible deployment sequences: sequences deploy steps using lock-minimizing patterns like CONCURRENTLY indexes, NOT VALID constraints, batched backfills, and validation phases.
  • Operational and rollback concrete requirements: budgets lock impact and WAL/replica-lag effects, names restore points/PITR feasibility, and specifies rollback triggers and observability for locks, deadlocks, and replication lag.

Quick Start

Use postgres-domain-delivery to implement or review the Postgres migration for your target change while capturing the smallest scoped evidence and a reversible rollback path.

Frequently Asked Questions about postgres-domain-delivery

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I run safe PostgreSQL migrations without locking tables in production?

PostgreSQL rollback discipline requires naming concrete restore points, verifying PITR feasibility, and defining explicit rollback triggers alongside observability for locks, deadlocks, and replication lag before deploying changes.

How do I verify a PostgreSQL index strategy actually improves query performance?

You verify a PostgreSQL index strategy by gathering explicit evidence from local source-of-truth using query-plan inspection, requiring EXPLAIN (ANALYZE, BUFFERS)-style proof to validate index designs against actual hot-query shapes.

What is transaction isolation's role when planning reversible PostgreSQL schema changes?

Transaction isolation semantics ensure PostgreSQL schema changes maintain data consistency during mixed-version deployments, requiring explicit verification evidence and structured PASS/PARTIAL/BLOCKED status output to confirm operational readiness.

How do I plan PostgreSQL backfill deployments that minimize WAL and replica lag?

Plan PostgreSQL backfill deployments using batched processing sequences that budget WAL and replica-lag effects, incorporating validation phases and operational observability to monitor replication-sensitive changes throughout execution.

When should I not use CONCURRENTLY for PostgreSQL index creation?

You should avoid CONCURRENTLY index creation when operating under strict transaction isolation constraints or when query-plan inspection reveals incompatible locking patterns, requiring structured BLOCKED status output instead of proceeding.