Postgresql
Design PostgreSQL tables, types, indexes, partitioning, and RLS with opinionated defaults before migrations hit production.
Overview
PostgreSQL is an agent skill for the Build phase that guides PostgreSQL-specific schema design—types, constraints, indexing, partitioning, RLS, and safe migration habits.
Install
npx skills add https://github.com/sickn33/antigravity-awesome-skills --skill postgresqlWhat is this skill?
- Five-step workflow: capture entities and access patterns, choose types and constraints, index real query paths with `EXP
- Primary key guidance: `BIGINT GENERATED ALWAYS AS IDENTITY` by default; UUID only when global uniqueness or opacity is r
- Normalize to 3NF first; denormalize only with measured justification for hot paths
- Explicit do-not-use guardrails for non-Postgres targets and query-only tuning without schema work
- Safety section: no destructive production DDL without backups, rollback plans, and staged validation
- 5-step design workflow in Instructions
- Normalize first to 3NF before denormalizing
Adoption & trust: 535 installs on skills.sh; 40.1k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are modeling data in Postgres but your schema drifts into wrong types, missing constraints, and indexes that do not match real queries, creating pain at scale.
Who is it for?
Indie SaaS or API builders choosing Postgres as the primary store who want agent-assisted DDL and review before shipping multi-tenant or high-row-count features.
Skip if: Projects on MySQL, SQLite-only prototypes, or teams that only need one-off `EXPLAIN` tuning with no schema or migration changes.
When should I use this skill?
Designing a schema for PostgreSQL, selecting data types and constraints, planning indexes partitions or RLS, or reviewing tables for scale and maintainability.
What do I get? / Deliverables
You get a normalized, constraint-backed PostgreSQL schema plan with indexes tied to verified query paths and a staged migration approach that avoids reckless production DDL.
- Schema definition with types constraints and keys
- Index and partition or RLS plan aligned to query paths
- Migration and rollback notes for staging validation
Recommended Skills
Journey fit
Schema design is a core Build activity once you are implementing persistence for a real product backend on PostgreSQL. Backend is the canonical shelf because the skill centers on DDL, constraints, indexing for query paths, and scale patterns—not frontend layout or launch SEO.
How it compares
A Postgres schema design playbook—not a generic ORM tutorial or a hosted database provisioning skill.
Common Questions / FAQ
Who is postgresql for?
Solo and small-team backend builders using PostgreSQL who want structured agent help for tables, constraints, indexes, partitions, and RLS before code ships.
When should I use postgresql?
During Build backend work when defining new tables, evolving schemas for scale, or reviewing an existing Postgres model for maintainability and query-aligned indexes.
Is postgresql safe to install?
The skill advocates backups and staging before DDL; it does not execute migrations by itself. Review the Security Audits panel on this Prism page before granting agents shell or database access in production environments.
SKILL.md
READMESKILL.md - Postgresql
# PostgreSQL Table Design ## Use this skill when - Designing a schema for PostgreSQL - Selecting data types and constraints - Planning indexes, partitions, or RLS policies - Reviewing tables for scale and maintainability ## Do not use this skill when - You are targeting a non-PostgreSQL database - You only need query tuning without schema changes - You require a DB-agnostic modeling guide ## Instructions 1. Capture entities, access patterns, and scale targets (rows, QPS, retention). 2. Choose data types and constraints that enforce invariants. 3. Add indexes for real query paths and validate with `EXPLAIN`. 4. Plan partitioning or RLS where required by scale or access control. 5. Review migration impact and apply changes safely. ## Safety - Avoid destructive DDL on production without backups and a rollback plan. - Use migrations and staging validation before applying schema changes. ## Core Rules - Define a **PRIMARY KEY** for reference tables (users, orders, etc.). Not always needed for time-series/event/log data. When used, prefer `BIGINT GENERATED ALWAYS AS IDENTITY`; use `UUID` only when global uniqueness/opacity is needed. - **Normalize first (to 3NF)** to eliminate data redundancy and update anomalies; denormalize **only** for measured, high-ROI reads where join performance is proven problematic. Premature denormalization creates maintenance burden. - Add **NOT NULL** everywhere it’s semantically required; use **DEFAULT**s for common values. - Create **indexes for access paths you actually query**: PK/unique (auto), **FK columns (manual!)**, frequent filters/sorts, and join keys. - Prefer **TIMESTAMPTZ** for event time; **NUMERIC** for money; **TEXT** for strings; **BIGINT** for integer values, **DOUBLE PRECISION** for floats (or `NUMERIC` for exact decimal arithmetic). ## PostgreSQL “Gotchas” - **Identifiers**: unquoted → lowercased. Avoid quoted/mixed-case names. Convention: use `snake_case` for table/column names. - **Unique + NULLs**: UNIQUE allows multiple NULLs. Use `UNIQUE (...) NULLS NOT DISTINCT` (PG15+) to restrict to one NULL. - **FK indexes**: PostgreSQL **does not** auto-index FK columns. Add them. - **No silent coercions**: length/precision overflows error out (no truncation). Example: inserting 999 into `NUMERIC(2,0)` fails with error, unlike some databases that silently truncate or round. - **Sequences/identity have gaps** (normal; don't "fix"). Rollbacks, crashes, and concurrent transactions create gaps in ID sequences (1, 2, 5, 6...). This is expected behavior—don't try to make IDs consecutive. - **Heap storage**: no clustered PK by default (unlike SQL Server/MySQL InnoDB); `CLUSTER` is one-off reorganization, not maintained on subsequent inserts. Row order on disk is insertion order unless explicitly clustered. - **MVCC**: updates/deletes leave dead tuples; vacuum handles them—design to avoid hot wide-row churn. ## Data Types - **IDs**: `BIGINT GENERATED ALWAYS AS IDENTITY` preferred (`GENERATED BY DEFAULT` also fine); `UUID` when merging/federating/used in a distributed system or for opaque IDs. Generate with `uuidv7()` (preferred if using PG18+) or `gen_random_uuid()` (if using an older PG version). - **Integers**: prefer `BIGINT` unless storage space is critical; `INTEGER` for smaller ranges; avoid `SMALLINT` unless constrained. - **Floats**: prefer `DOUBLE PRECISION` over `REAL` unless storage space is critical. Use `NUMERIC` for exact decimal arithmetic. - **Strings**: prefer `TEXT`; if length limits needed, use `CHECK (LENGTH(col) <= n)` instead of `VARCHAR(n)`; avoid `CHAR(n)`. Use `BYTEA` for binary data. Large strings/binary (>2KB default threshold) automatically stored in TOAST with compression. TOAST storage: `PLAIN` (no TOAST), `EXTENDED` (com