Database and Postgres Skills

Best for: A Postgres rulebook the agent consults while writing queries

The most installed database skill in the registry is a library of Postgres performance rules sorted by how much damage ignoring them causes. Eight categories run from critical (query performance, connection management, security and RLS) down to advanced features, and each rule file pairs an incorrect SQL example with a corrected one, often with EXPLAIN output showing the difference. The skill is versioned like software; v1.1.1 dates from January 2026.

Nothing in it requires Supabase. The rules are plain Postgres: missing and partial indexes, connection pooling, lock behavior, and RLS policies that cache auth.uid() in a subquery instead of re-evaluating it on every row. That portability explains the 282K installs; teams on RDS or bare Postgres install it alongside Supabase users, and the Supabase-specific notes stay out of the way when they do not apply.

• 282K installs, the registry's top database skill
• Eight rule categories prioritized from critical to incremental
• Every rule shows incorrect and correct SQL, many with EXPLAIN
• Plain Postgres rules that apply on any host

Best for: Real Supabase projects: auth, RLS, migrations, and the CLI

The platform skill opens with the instruction that explains most Supabase agent failures: do not trust training data. The agent must fetch the changelog and current docs first, because function signatures and config conventions change between versions, and it must discover CLI commands with --help instead of inventing them. Exact version gates are named, like supabase db query requiring CLI v2.79.0 and db advisors requiring v2.81.3, with MCP fallbacks for older installs.

The security checklist is the part worth the install. It walks the traps that ship silent vulnerabilities: views bypass RLS unless created with security_invoker = true, an UPDATE without a SELECT policy returns zero rows with no error, an UPDATE policy without WITH CHECK lets a user reassign rows to someone else, and a SECURITY DEFINER function in the public schema is callable by every role by default. Each is a bug class agents write confidently and users discover in production.

• Fetches the changelog before implementing anything
• CLI discovery via --help, with named version gates
• Security checklist for RLS, views, JWT claims, and storage
• Separate declarative and imperative migration workflows

Best for: Agent experiments on full production data, safely

Neon's official skill is organized around the platform feature that matters most for agent work: branches are instant copy-on-write clones, so an agent can rehearse a destructive migration against a full copy of production data without touching production. Setup is one command, npx -y neon@latest init --agent claude, which installs the MCP server, mints an API key, and adds the skill; ten agent names are supported, from Cursor to Zed.

The rest is judgment about runtimes. It tells the agent to use node-postgres with a module-scope pool on hosts that keep instances alive, like Vercel's fluid compute, and the HTTP-based serverless driver on per-request isolated hosts like Netlify, a distinction that produces mysterious connection exhaustion when gotten wrong. A neon.ts infrastructure-as-code file with plan and apply semantics lets non-production branches expire after seven days and scale to zero. Neon has been part of Databricks since May 2025, and the free tier still allows 100 projects.

• Branches are copy-on-write clones of full production data
• One init command wires MCP, keys, and skill for ten agents
• Driver selection mapped to runtime isolation model
• neon.ts gives branches TTLs and scale-to-zero defaults

Best for: Teaching the agent to read a query plan before indexing

A vendor-neutral reference for the slow-query conversation. It starts with EXPLAIN and what to look for: sequential scans on large tables, index-only scans as the goal, and when a nested loop, hash, or merge join is the right shape. From there it catalogs index types past the default B-tree: partial indexes over a WHERE subset, expression indexes for LOWER(email), covering indexes with INCLUDE, GIN for JSONB and full text, BRIN for huge append-only tables.

The pitfalls list is the part agents need most: a function in the WHERE clause silently disables an index, a leading-wildcard LIKE cannot use one at all, and every added index taxes writes. It closes with the pg_stat_statements and pg_stat_user_tables queries that surface slow queries, missing indexes, and unused ones, turning a vague performance complaint into a ranked list of fixes.

• EXPLAIN ANALYZE reading guide, scan and join types included
• Six index types with the case for each, B-tree to BRIN
• Names the index killers: functions in WHERE, leading wildcards
• Ready-made pg_stat_statements slow-query hunts

Best for: Schema changes that survive rollback and stay online

Covers the discipline agents skip when asked to rename a column: expand and contract. Add the new column, backfill it, switch the application over, and only then drop the old one, three deploys in place of one destructive ALTER. Worked examples run in Sequelize, TypeORM, and Prisma, and every migration ships with a working down function, which agents left alone tend to stub out or omit.

The rollback section goes further than most teams do by hand: transaction-wrapped migrations that revert on any error, and a checkpoint pattern that snapshots the table to a backup before a risky transformation, verifies the result afterward, and restores from the backup when verification fails. Since several of the incidents this page opens with began as migrations, a skill that writes reversible ones by default earns its slot.

• Expand-and-contract renames instead of destructive ALTERs
• Every worked example includes a functioning down migration
• Checkpoint pattern: snapshot, verify, restore on failure
• Same patterns in Sequelize, TypeORM, and Prisma syntax

Best for: Stopping agents from writing Prisma 6 code in a v7 project

Prisma ships this skill because agent training data is full of older Prisma. Version 7 moved datasource URLs into prisma.config.ts and made driver adapters the standard SQL path, so an agent working from memory produces configuration that no longer parses. The skill's tables map each database to its adapter and driver: @prisma/adapter-pg with pg for Postgres and CockroachDB, the mariadb adapter for MySQL, better-sqlite3 or libsql for SQLite and Turso.

The sharpest rule concerns MongoDB: stay on Prisma 6.x, keep the URL in schema.prisma, and never install a SQL adapter for it, because the v7 workflow does not apply. Prerequisites are stated exactly (Node 20.19+, TypeScript 5.4+), Bun users get the bunx --bun invocation so the CLI runs on the intended runtime, and the skill itself is versioned against the ORM release line, currently 7.6.0.

• Counters stale training data with Prisma 7 config patterns
• Adapter and driver table covering seven database targets
• MongoDB rule: stay on 6.x, no SQL adapters
• Versioned with the ORM, currently 7.6.0

Best for: A reactive TypeScript backend the agent can verify itself

Convex is a reactive TypeScript backend rather than a Postgres flavor, and its quickstart is built around a loop agents can actually use: npx convex dev --once provisions an anonymous local deployment on 127.0.0.1, pushes the convex/ directory, validates the schema, typechecks the functions, and exits cleanly. The output tells the agent whether the code it just wrote is broken, with no browser login and no team prompts in the way.

Setting CONVEX_AGENT_MODE=anonymous makes that behavior explicit instead of depending on TTY detection, the kind of detail that separates skills written for agents from docs adapted for them. Seven scaffold templates cover Vite, Next.js, and three auth providers. The suite around it runs deep; setup-auth, migration-helper, and performance-audit each sit above 82K installs, and the quickstart routes to them by name when a task outgrows it.

• convex dev --once: provision, push, validate, typecheck, exit
• Anonymous local deployments, no login needed for agents
• Seven templates across Vite, Next.js, and auth providers
• Routes to sibling skills for auth, migrations, and audits

Best for: Schema and query review for analytics workloads

ClickHouse wrote the strictest skill on this page: 31 rules across schema, query, insert, and agent categories, with an instruction to cite the specific rule name in every recommendation. The strictness exists because columnar databases punish relational instinct. ORDER BY is immutable after CREATE TABLE, ALTER UPDATE is banned in favor of ReplacingMergeTree because mutations are expensive, inserts should batch 10K to 100K rows, and partition counts belong between 100 and 1,000.

The agent-facing rules are ahead of most vendors. A seven-step schema discovery workflow runs before any query: databases, tables, columns and comments, sort keys, skip indexes, a sample, then EXPLAIN. A query-safety rule mandates LIMIT and timeouts with progressive narrowing after memory errors. Review checklists for CREATE TABLE and JOIN work feed an output format that reports which rules were checked and which were violated, so a review becomes auditable instead of vibes.

• 31 rules, and recommendations must cite them by name
• Schema rules: ORDER BY is forever, avoid Nullable
• Insert discipline: 10K to 100K row batches, no OPTIMIZE FINAL
• Agent safety: discover schema first, always LIMIT

Best for: Choosing the right Redis structure before writing keys

Redis keeps this skill small on purpose: two decisions drive most Redis outcomes, and it covers exactly those. The first is structure selection by access pattern rather than data shape: a Hash for objects whose fields update independently, a Sorted Set for leaderboards, a Stream for event logs with consumer groups, a Vector Set for similarity search. The named anti-pattern is one agents produce constantly, serializing a whole object into a String so that changing one field means fetch, parse, mutate, and rewrite.

The second decision is key naming: lowercase colon-separated hierarchies like user:1001:profile, short but readable, tenant-prefixed where multi-tenancy matters so scans and ACLs can target one tenant cleanly. Seven sibling skills from the same repo go deeper on clustering, security, and semantic caching. At 1.1K installs this is the least adopted pick on the page, and the one we expect to age best as the suite fills out.

• Maps access patterns to the eight Redis data types
• Calls out the serialized-object String anti-pattern
• Key naming: colon hierarchies, tenant prefixes
• Entry point to Redis's suite of deeper skills

Best for: Diagnosing slow MongoDB queries with evidence

MongoDB scoped this skill to a single trigger, performance, and tells the agent to stay out of routine query writing. When invoked it works through the MongoDB MCP server: list the collection's indexes, run explain in queryPlanner mode to catch COLLSCANs, escalate to executionStats to compare documents scanned against documents returned, then fetch one sample document to infer the schema. On Atlas it adds the Performance Advisor for slow query logs, suggested indexes, and drop suggestions.

The worked example shows the diagnostic style: a query returning 100 documents while scanning 50,000 index entries, fixed with a compound index ordered by the ESR rule, equality fields first, then sort, then range. The guardrails stand out for a vendor skill: keep collections under roughly 20 indexes, suggest removals only when the Advisor does, phrase recommendations as suggestions with reasoning, and never create an index through MCP without explicit approval.

• explain-first: COLLSCAN check, then executionStats
• Compound indexes ordered by the ESR rule
• Atlas Performance Advisor for cluster-wide slow queries
• Will not create indexes without the user's approval