sota-databaseslisted
State-of-the-art database engineering rules (2026) for designing, building, and auditing data layers. Covers engine selection, schema modeling, migrations, query and index craft, transactions and concurrency, reliability and scale, security, and vector/AI workloads. Use when designing a new data layer, writing or reviewing schemas/migrations/queries, debugging slow or contended database workloads, or auditing an existing database for correctness, performance, and security. Not for ETL or streaming data pipelines — use sota-data-engineering. Trigger keywords: database, SQL, Postgres, schema, migration, index, query, ORM, transaction, NoSQL, Redis, vector DB, pgvector, replication, partitioning, connection pool, RLS, EXPLAIN, deadlock, sharding, caching, SurrealDB, SurrealQL, Qdrant, multi-model, graph database.
martinholovsky/SOTA-skills · ★ 8 · API & Backend · score 75
Install: claude install-skill martinholovsky/SOTA-skills
# SOTA Databases
Expert-level rules for the full lifecycle of a data layer: choosing an engine,
modeling data, evolving schemas safely, writing efficient queries, handling
concurrency, operating reliably at scale, securing data, and supporting
vector/AI workloads. Postgres is the reference engine; rules call out where
other systems (MySQL, Redis, document/columnar/vector stores) differ.
This skill operates in two modes. Determine the mode from the user's intent,
then load the relevant `rules/` files per the index below. Do not load all
files preemptively — pick by task.
## BUILD mode
Use when designing or implementing: new schemas, migrations, queries, ORM
layers, caching, job queues, or database infrastructure.
1. **Engine and model first.** Read `rules/01-choosing-and-modeling.md` before
writing any DDL. Default to Postgres unless a rule there says otherwise.
2. **Every schema change is a migration.** Never hand the user raw DDL to run
ad hoc; produce migration files following `rules/02-schema-migrations.md`
(expand/contract, lock-aware, reversible-or-documented).
3. **Design indexes with the queries, not after.** When writing a query that
will run in production, state which index serves it. Follow
`rules/03-queries-and-indexes.md`.
4. **State the concurrency story.** For any write path: idempotency, isolation
level, locking strategy, retry behavior (`rules/04-transactions-concurrency.md`).
5. **Operational defaults are part of the design.** Pooling,