Agent skill

Design Postgres Tables

by timescale in timescale/pg-aiguide

A skill your agent uses for general PostgreSQL table design.

Apache-2.0Auto-check passedDatabases

Install Design Postgres Tables

skills CLI
$ npx skills add timescale/pg-aiguide --skill design-postgres-tables -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install timescale/pg-aiguide design-postgres-tables --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/timescale/pg-aiguide.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/design-postgres-tables .claude/skills/design-postgres-tables && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
design-postgres-tables
GitHub stars
1.9k
Token cost
~4.2k tokens
SKILL.md length
1,845 words
Files
1
Skills in repo
9
Repo updated
First seen
Licence
Apache-2.0

At a glance

A skill your agent uses for general PostgreSQL table design.

  • General PostgreSQL table design
  • SKILL.md covers Core Rules, PostgreSQL “Gotchas”, Data Types and Table Types, plus 9 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md
  • User asks to: - Design PostgreSQL tables

What it does

Design Postgres Tables is an agent skill from timescale/pg-aiguide. Use this skill for general PostgreSQL table design. Trigger when user asks to: - Design PostgreSQL tables, schemas, or data models when creating new tables and when modifying existing ones. - Choose data types, constraints, or indexes for PostgreSQL - Create user tables, order tables, reference tables, or JSONB schemas - Understand PostgreSQL best practices for normalization, constraints, or indexing - Design update-heavy, upsert-heavy, or OLTP-style tables Keywords: PostgreSQL schema, table design, data types…

Its SKILL.md is about 4.2k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Databases, covering Database schema design. It works with PostgreSQL and Model Context Protocol. The repository describes itself as: MCP server and Claude plugin for Postgres skills and documentation. Helps AI coding tools generate better PostgreSQL code. The licence is Apache-2.0.

When your agent uses it

  • General PostgreSQL table design
  • User asks to: - Design PostgreSQL tables
  • Data models when creating new tables and when modifying existing ones

Example prompts

  • “/design-postgres-tables”

What it can do on your machine

Read from SKILL.md and the folder at commit b236d35. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are sql).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Design Postgres Tables loads about 4.2k tokens when it runs. Until then it costs about 209 tokens; SKILL.md has 1,845 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~209
When it runs · the whole SKILL.md, loaded when a task matches
~4.2k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from timescale/pg-aiguide at commit b236d35, republished under its Apache-2.0 licence (© timescale). 1,845 words, ~4,208 tokens.

Download SKILL.mdSave it as .claude/skills/design-postgres-tables/SKILL.md (or your agent's skills folder).
name
design-postgres-tables
description
Use this skill for general PostgreSQL table design. **Trigger when user asks to:** - Design PostgreSQL tables, schemas, or data models when creating new tables and when modifying existing ones. - Choose data types, constraints, or indexes for PostgreSQL - Create user tables, order tables, reference tables, or JSONB schemas - Understand PostgreSQL best practices for normalization, constraints, or indexing - Design update-heavy, upsert-heavy, or OLTP-style tables **Keywords:** PostgreSQL schema, table design, data types, PRIMARY KEY, FOREIGN KEY, indexes, B-tree, GIN, JSONB, constraints, normalization, identity columns, partitioning, row-level security Comprehensive reference covering data types, indexing strategies, constraints, JSONB patterns, partitioning, and PostgreSQL-specific best practices.
license
Apache-2.0
metadata.author
tigerdata

PostgreSQL Table Design

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 DEFAULTs 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 (compress + out-of-line), EXTERNAL (out-of-line, no compress), MAIN (compress, keep in-line if possible). Default EXTENDED usually optimal. Control with ALTER TABLE tbl ALTER COLUMN col SET STORAGE strategy and ALTER TABLE tbl SET (toast_tuple_target = 4096) for threshold. Case-insensitive: for locale/accent handling use non-deterministic collations; for plain ASCII use expression indexes on LOWER(col) (preferred unless column needs case-insensitive PK/FK/UNIQUE) or CITEXT.
  • Money: NUMERIC(p,s) (never float).
  • Time: TIMESTAMPTZ for timestamps; DATE for date-only; INTERVAL for durations. Avoid TIMESTAMP (without timezone). Use now() for transaction start time, clock_timestamp() for current wall-clock time.
  • Booleans: BOOLEAN with NOT NULL constraint unless tri-state values are required.
  • Enums: CREATE TYPE ... AS ENUM for small, stable sets (e.g. US states, days of week). For business-logic-driven and evolving values (e.g. order statuses) → use TEXT (or INT) + CHECK or lookup table.
  • Arrays: TEXT[], INTEGER[], etc. Use for ordered lists where you query elements. Index with GIN for containment (@>, <@) and overlap (&&) queries. Access: arr[1] (1-indexed), arr[1:3] (slicing). Good for tags, categories; avoid for relations—use junction tables instead. Literal syntax: '{val1,val2}' or ARRAY[val1,val2].
  • Range types: daterange, numrange, tstzrange for intervals. Support overlap (&&), containment (@>), operators. Index with GiST. Good for scheduling, versioning, numeric ranges. Pick a bounds scheme and use it consistently; prefer [) (inclusive/exclusive) by default.
  • Network types: INET for IP addresses, CIDR for network ranges, MACADDR for MAC addresses. Support network operators (<<, >>, &&).
  • Geometric types: avoid POINT, LINE, POLYGON, CIRCLE. Index with GiST. Consider PostGIS for spatial features.
  • Text search: TSVECTOR for full-text search documents, TSQUERY for search queries. Index tsvector with GIN. Always specify language: to_tsvector('english', col) and to_tsquery('english', 'query'). Never use single-argument versions. This applies to both index expressions and queries.
  • Domain types: CREATE DOMAIN email AS TEXT CHECK (VALUE ~ '^[^@]+@[^@]+$') for reusable custom types with validation. Enforces constraints across tables.
  • Composite types: CREATE TYPE address AS (street TEXT, city TEXT, zip TEXT) for structured data within columns. Access with (col).field syntax.
  • JSONB: preferred over JSON; index with GIN. Use only for optional/semi-structured attrs. ONLY use JSON if the original ordering of the contents MUST be preserved.
  • Vector types: vector type by pgvector for vector similarity search for embeddings.
Do not use the following data types
  • DO NOT use timestamp (without time zone); DO use timestamptz instead.
  • DO NOT use char(n) or varchar(n); DO use text instead.
  • DO NOT use money type; DO use numeric instead.
  • DO NOT use timetz type; DO use timestamptz instead.
  • DO NOT use timestamptz(0) or any other precision specification; DO use timestamptz instead
  • DO NOT use serial type; DO use generated always as identity instead.
  • DO NOT use POINT, LINE, POLYGON, CIRCLE built-in types, DO use geometry from postgis extension instead.

Table Types

  • Regular: default; fully durable, logged.
  • TEMPORARY: session-scoped, auto-dropped, not logged. Faster for scratch work.
  • UNLOGGED: persistent but not crash-safe. Faster writes; good for caches/staging.

Row-Level Security

Enable with ALTER TABLE tbl ENABLE ROW LEVEL SECURITY. Create policies: CREATE POLICY user_access ON orders FOR SELECT TO app_users USING (user_id = current_user_id()). Built-in user-based access control at the row level.

Constraints

  • PK: implicit UNIQUE + NOT NULL; creates a B-tree index.
  • FK: specify ON DELETE/UPDATE action (CASCADE, RESTRICT, SET NULL, SET DEFAULT). Add explicit index on referencing column—speeds up joins and prevents locking issues on parent deletes/updates. Use DEFERRABLE INITIALLY DEFERRED for circular FK dependencies checked at transaction end.
  • UNIQUE: creates a B-tree index; allows multiple NULLs unless NULLS NOT DISTINCT (PG15+). Standard behavior: (1, NULL) and (1, NULL) are allowed. With NULLS NOT DISTINCT: only one (1, NULL) allowed. Prefer NULLS NOT DISTINCT unless you specifically need duplicate NULLs.
  • CHECK: row-local constraints; NULL values pass the check (three-valued logic). Example: CHECK (price > 0) allows NULL prices. Combine with NOT NULL to enforce: price NUMERIC NOT NULL CHECK (price > 0).
  • EXCLUDE: prevents overlapping values using operators. EXCLUDE USING gist (room_id WITH =, booking_period WITH &&) prevents double-booking rooms. Requires appropriate index type (often GiST).

Indexing

  • B-tree: default for equality/range queries (=, <, >, BETWEEN, ORDER BY)
  • Composite: order matters—index used if equality on leftmost prefix (WHERE a = ? AND b > ? uses index on (a,b), but WHERE b = ? does not). Put most selective/frequently filtered columns first.
  • Covering: CREATE INDEX ON tbl (id) INCLUDE (name, email) - includes non-key columns for index-only scans without visiting table.
  • Partial: for hot subsets (WHERE status = 'active' → CREATE INDEX ON tbl (user_id) WHERE status = 'active'). Any query with status = 'active' can use this index.
  • Expression: for computed search keys (CREATE INDEX ON tbl (LOWER(email))). Expression must match exactly in WHERE clause: WHERE LOWER(email) = 'user@example.com'.
  • GIN: JSONB containment/existence, arrays (@>, ?), full-text search (@@)
  • GiST: ranges, geometry, exclusion constraints
  • BRIN: very large, naturally ordered data (time-series)—minimal storage overhead. Effective when row order on disk correlates with indexed column (insertion order or after CLUSTER).
Show full SKILL.md (709 more words)Show less

Partitioning

  • Use for very large tables (>100M rows) where queries consistently filter on partition key (often time/date).
  • Alternate use: use for tables where data maintenance tasks dictates e.g. data pruned or bulk replaced periodically
  • RANGE: common for time-series (PARTITION BY RANGE (created_at)). Create partitions: CREATE TABLE logs_2024_01 PARTITION OF logs FOR VALUES FROM ('2024-01-01') TO ('2024-02-01'). TimescaleDB automates time-based or ID-based partitioning with retention policies and compression.
  • LIST: for discrete values (PARTITION BY LIST (region)). Example: FOR VALUES IN ('us-east', 'us-west').
  • HASH: for even distribution when no natural key (PARTITION BY HASH (user_id)). Creates N partitions with modulus.
  • Constraint exclusion: requires CHECK constraints on partitions for query planner to prune. Auto-created for declarative partitioning (PG10+).
  • Prefer declarative partitioning or hypertables. Do NOT use table inheritance.
  • Limitations: no global UNIQUE constraints—include partition key in PK/UNIQUE. FKs from partitioned tables not supported; use triggers.

Special Considerations

Update-Heavy Tables
  • Separate hot/cold columns—put frequently updated columns in separate table to minimize bloat.
  • Use fillfactor=90 to leave space for HOT updates that avoid index maintenance.
  • Avoid updating indexed columns—prevents beneficial HOT updates.
  • Partition by update patterns—separate frequently updated rows in a different partition from stable data.
Insert-Heavy Workloads
  • Minimize indexes—only create what you query; every index slows inserts.
  • Use COPY or multi-row INSERT instead of single-row inserts.
  • UNLOGGED tables for rebuildable staging data—much faster writes.
  • Defer index creation for bulk loads—>drop index, load data, recreate indexes.
  • Partition by time/hash to distribute load. TimescaleDB automates partitioning and compression of insert-heavy data.
  • Use a natural key for primary key such as a (timestamp, device_id) if enforcing global uniqueness is important many insert-heavy tables don't need a primary key at all.
  • If you do need a surrogate key, Prefer BIGINT GENERATED ALWAYS AS IDENTITY over UUID.
Upsert-Friendly Design
  • Requires UNIQUE index on conflict target columns—ON CONFLICT (col1, col2) needs exact matching unique index (partial indexes don't work).
  • Use EXCLUDED.column to reference would-be-inserted values; only update columns that actually changed to reduce write overhead.
  • DO NOTHING faster than DO UPDATE when no actual update needed.
Safe Schema Evolution
  • Transactional DDL: most DDL operations can run in transactions and be rolled back—BEGIN; ALTER TABLE...; ROLLBACK; for safe testing.
  • Concurrent index creation: CREATE INDEX CONCURRENTLY avoids blocking writes but can't run in transactions.
  • Volatile defaults cause rewrites: adding NOT NULL columns with volatile defaults (e.g., now(), gen_random_uuid()) rewrites entire table. Non-volatile defaults are fast.
  • Drop constraints before columns: ALTER TABLE DROP CONSTRAINT then DROP COLUMN to avoid dependency issues.
  • Function signature changes: CREATE OR REPLACE with different arguments creates overloads, not replacements. DROP old version if no overload desired.

Generated Columns

  • ... GENERATED ALWAYS AS (<expr>) STORED for computed, indexable fields. PG18+ adds VIRTUAL columns (computed on read, not stored).

Extensions

  • pgcrypto: crypt() for password hashing.
  • uuid-ossp: alternative UUID functions; prefer pgcrypto for new projects.
  • pg_trgm: fuzzy text search with % operator, similarity() function. Index with GIN for LIKE '%pattern%' acceleration.
  • citext: case-insensitive text type. Prefer expression indexes on LOWER(col) unless you need case-insensitive constraints.
  • btree_gin/btree_gist: enable mixed-type indexes (e.g., GIN index on both JSONB and text columns).
  • hstore: key-value pairs; mostly superseded by JSONB but useful for simple string mappings.
  • timescaledb: essential for time-series—automated partitioning, retention, compression, continuous aggregates.
  • postgis: comprehensive geospatial support beyond basic geometric types—essential for location-based applications.
  • pgvector: vector similarity search for embeddings.
  • pgaudit: audit logging for all database activity.

JSONB Guidance

  • Prefer JSONB with GIN index.
  • Default: CREATE INDEX ON tbl USING GIN (jsonb_col); → accelerates:
    • Containment jsonb_col @> '{"k":"v"}'
    • Key existence jsonb_col ? 'k', any/all keys ?\|, ?&
    • Path containment on nested docs
    • Disjunction jsonb_col @> ANY(ARRAY['{"status":"active"}', '{"status":"pending"}'])
  • Heavy @> workloads: consider opclass jsonb_path_ops for smaller/faster containment-only indexes:
    • CREATE INDEX ON tbl USING GIN (jsonb_col jsonb_path_ops);
    • Trade-off: loses support for key existence (?, ?|, ?&) queries—only supports containment (@>)
  • Equality/range on a specific scalar field: extract and index with B-tree (generated column or expression):
    • ALTER TABLE tbl ADD COLUMN price INT GENERATED ALWAYS AS ((jsonb_col->>'price')::INT) STORED;
    • CREATE INDEX ON tbl (price);
    • Prefer queries like WHERE price BETWEEN 100 AND 500 (uses B-tree) over WHERE (jsonb_col->>'price')::INT BETWEEN 100 AND 500 without index.
  • Arrays inside JSONB: use GIN + @> for containment (e.g., tags). Consider jsonb_path_ops if only doing containment.
  • Keep core relations in tables; use JSONB for optional/variable attributes.
  • Use constraints to limit allowed JSONB values in a column e.g. config JSONB NOT NULL CHECK(jsonb_typeof(config) = 'object')

Examples

Users
sql
CREATE TABLE users (
  user_id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  email TEXT NOT NULL UNIQUE,
  name TEXT NOT NULL,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);
CREATE UNIQUE INDEX ON users (LOWER(email));
CREATE INDEX ON users (created_at);
Orders
sql
CREATE TABLE orders (
  order_id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  user_id BIGINT NOT NULL REFERENCES users(user_id),
  status TEXT NOT NULL DEFAULT 'PENDING' CHECK (status IN ('PENDING','PAID','CANCELED')),
  total NUMERIC(10,2) NOT NULL CHECK (total > 0),
  created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);
CREATE INDEX ON orders (user_id);
CREATE INDEX ON orders (created_at);
JSONB
sql
CREATE TABLE profiles (
  user_id BIGINT PRIMARY KEY REFERENCES users(user_id),
  attrs JSONB NOT NULL DEFAULT '{}',
  theme TEXT GENERATED ALWAYS AS (attrs->>'theme') STORED
);
CREATE INDEX profiles_attrs_gin ON profiles USING GIN (attrs);

© timescale, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/design-postgres-tables of timescale/pg-aiguide.

Open the folder on GitHubat commit b236d35

Compare with similar skills

Design Postgres Tables next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Design Postgres Tables compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Design Postgres Tables this skilltimescale/pg-aiguide1.9k—~4.2kAutomated safety check: PassApache-2.0
Supabase Postgres Best Practicessupabase/agent-skills2.7k24 repos~808Automated safety check: PassMIT
Codebase Explorationgiancarloerra/SocratiCode3.3k1 repos~1.5kAutomated safety check: PassAGPL-3.0
Saleor Django Migration Rulessaleor/saleor23k—~1.6kAutomated safety check: PassBSD-3-Clause
Database DesignMoizIbnYousaf/ai-agent-skills1.1k1 repos~1.2kAutomated safety check: PassMIT
Neon Postgressmontlouis/bible-strong1711 repos~2.3kAutomated safety check: NotesGPL-3.0

Similar skills

  • Official

    Gives the agent Postgres rules to consult before writing or changing tables, queries, indexes, RLS policies or migrations, and when diagnosing slow queries.

    2.7k GitHub starsUsed in 24 repos~808 tokens
    DatabasesAuto-check passed
  • Codebase Exploration

    giancarloerra/SocratiCode

    Explore and understand codebases using SocratiCode semantic search, dependency graphs, and context artifacts.

    3.3k GitHub starsUsed in 1 repo~1.5k tokens
    DatabasesAuto-check passed
  • Rules for writing Django migrations in Saleor that avoid long table locks and stay compatible with zero-downtime rolling deploys.

    23k GitHub stars~1.6k tokensUpdated yesterday
    DatabasesAuto-check passed
  • Database Design

    MoizIbnYousaf/ai-agent-skills

    Database schema design, optimization, and migration patterns for PostgreSQL, MySQL, and NoSQL databases.

    1.1k GitHub starsUsed in 1 repo~1.2k tokens
    DatabasesAuto-check passed
  • Neon Postgres

    smontlouis/bible-strong

    Guides and best practices for working with Lakebase Postgres, the database behind Neon.

    171 GitHub starsUsed in 1 repo~2.3k tokens
    DatabasesAuto-check: notes
  • PlanetScale Neki Overview

    planetscale/database-skills

    Official

    Overview and information about Neki, the sharded Postgres product by PlanetScale. Load when working with Neki-related tasks and the need to scale or shard…

    698 GitHub starsUsed in 1 repo~483 tokens
    DatabasesAuto-check passed

More from timescale/pg-aiguide

All 9 skills in this repo
  • Find Hypertable Candidates

    timescale/pg-aiguide

    A skill your agent uses to analyze an existing PostgreSQL database and identify which tables should be converted to Timescale/TimescaleDB hypertables.

    1.9k GitHub starsUsed in 1 repo~2.6k tokens
    Auto-check passed
  • Schema Exploration

    timescale/pg-aiguide

    Explore an existing PostgreSQL database before answering questions about its data or writing SQL.

    1.9k GitHub stars~1.1k tokensUpdated 5 days ago
    Auto-check passed
  • Pgvector Semantic Search

    timescale/pg-aiguide

    A skill your agent uses for setting up vector similarity search with pgvector for AI/ML embeddings, RAG applications, or semantic search.

    1.9k GitHub starsUsed in 1 repo~3.8k tokens
    Auto-check passed
  • A skill your agent uses to migrate identified PostgreSQL tables to Timescale/TimescaleDB hypertables with optimal configuration and validation.

    1.9k GitHub starsUsed in 1 repo~3.8k tokens
    Auto-check: warnings
  • Postgres Hybrid Text Search

    timescale/pg-aiguide

    A skill your agent uses to implement hybrid search combining BM25 keyword search with semantic vector search using Reciprocal Rank Fusion (RRF).

    1.9k GitHub stars~3.1k tokensUpdated 5 days ago
    Auto-check passed
  • Setup Timescaledb Hypertables

    timescale/pg-aiguide

    A skill your agent uses when creating database schemas or tables for Timescale, TimescaleDB, TigerData, or Tiger Cloud, especially for time-series, IoT, metrics, events, or log data.

    1.9k GitHub stars~4.7k tokensUpdated 5 days ago
    Auto-check passed

Categories

Questions about Design Postgres Tables

What does Design Postgres Tables do?

A skill your agent uses for general PostgreSQL table design. Design Postgres Tables is an agent skill from timescale/pg-aiguide. Use this skill for general PostgreSQL table design.

When should I use Design Postgres Tables?

Design Postgres Tables fits situations like: general PostgreSQL table design; user asks to: - Design PostgreSQL tables; data models when creating new tables and when modifying existing ones.

How do I install Design Postgres Tables in Claude Code?

Run `npx skills add timescale/pg-aiguide --skill design-postgres-tables -a claude-code`. Or copy the skill folder (skills/design-postgres-tables in timescale/pg-aiguide) into .claude/skills/design-postgres-tables in your project. Claude Code loads it when a task matches its description.

How do I install Design Postgres Tables in Codex?

Run `npx skills add timescale/pg-aiguide --skill design-postgres-tables -a codex`. Or copy the skill folder (skills/design-postgres-tables in timescale/pg-aiguide) into .agents/skills/design-postgres-tables in your project. Codex loads it when a task matches its description.

Can I use Design Postgres Tables in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add timescale/pg-aiguide --skill design-postgres-tables -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/design-postgres-tables, .gemini/skills/design-postgres-tables, .github/skills/design-postgres-tables and .opencode/skills/design-postgres-tables in your project.

What does Design Postgres Tables need to run?

SKILL.md names no scripts, command-line tools or credentials: Design Postgres Tables is instructions for the agent only.

Does Design Postgres Tables access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Design Postgres Tables safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Design Postgres Tables use?

Design Postgres Tables is published under the Apache-2.0 licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Design Postgres Tables use?

About 4.2k tokens (SKILL.md is roughly 17k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Design Postgres Tables?

Skills that share tags, products or a category with Design Postgres Tables: Supabase Postgres Best Practices (supabase/agent-skills, 2.7k stars), Codebase Exploration (giancarloerra/SocratiCode, 3.3k stars), Saleor Django Migration Rules (saleor/saleor, 23k stars) and Database Design (MoizIbnYousaf/ai-agent-skills, 1.1k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Design Postgres Tables?

timescale (a GitHub organization) maintains it in timescale/pg-aiguide, which has 1,857 GitHub stars. The repository holds 9 skills in this directory. The repository was last updated on October 1, 2026.

Source: timescale/pg-aiguide on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.