- Home
- Skills
- Nilecui
- Skillsbase
- Postgresql
postgresql_skill
- Python
20
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill nilecui/skillsbase --skill postgresql- SKILL.md15.7 KB
Overview
This skill designs PostgreSQL-specific schemas focused on robust, performant table layouts and realistic operational patterns. It codifies best-practices for keys, data types, indexing, partitioning, constraints, and workload-driven optimizations. The guidance balances normalization with pragmatic denormalization and covers advanced features like JSONB, range types, and extensions.
How this skill works
It inspects schema decisions and recommends concrete alternatives: primary key choices, proper data types, where to add indexes, and when to partition. It highlights PostgreSQL gotchas (MVCC, identifier rules, sequence gaps) and prescribes storage, VACUUM, and write-path optimizations. It also suggests specific index types and extension use for JSONB, geospatial, and vector workloads.
When to use it
- Designing a new PostgreSQL schema for OLTP or analytical workloads
- Optimizing read/write performance for large tables or time-series data
- Converting legacy schemas to PostgreSQL idioms and types
- Planning partitioning, retention, or maintenance strategies
- Evaluating use of JSONB, PostGIS, pgvector, or other extensions
Best practices
- Always define a primary key; prefer BIGINT GENERATED ALWAYS AS IDENTITY unless UUID is required
- Normalize to 3NF first; denormalize only for measured, high-ROI read patterns
- Use TIMESTAMPTZ for timestamps, NUMERIC for money, TEXT for strings; avoid timestamp without timezone and varchar/char
- Create indexes only for real query paths: PKs, UNIQUEs, FK columns, frequent filters/sorts; add FK indexes manually
- Partition very large tables (>100M rows) by time/hash when queries filter on the partition key; prefer declarative partitioning
- Design update-heavy tables to separate hot columns, set sensible fillfactor, and avoid updating indexed columns
Example use cases
- High-volume event logs: PARTITION BY RANGE(created_at), BRIN or GiST/BRIN for time-ordered reads
- E-commerce orders: BIGINT PK, FK indexes on customer_id, NUMERIC for prices, partial indexes for active orders
- User profile attributes: base columns normalized, optional attributes in JSONB with GIN index for flexible queries
- Scheduling/bookings: tstzrange columns with GiST index and EXCLUDE constraint to prevent overlaps
- Embedding search: pgvector column with appropriate index for nearest-neighbor similarity
FAQ
Use UUID when you need global uniqueness, opaque identifiers, or offline ID generation; otherwise prefer BIGINT identity for storage and performance.
Do I need an index on foreign keys?
Yes. PostgreSQL does not auto-index FK columns; add indexes to speed joins and avoid locking issues on parent deletes/updates.