Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →code-saurabh/database-architect
Expert database architecture and design guidance — schema/data modeling, ER diagrams, indexing, query optimization, partitioning, replication and high availability, transactions and locking, connection pooling, migrations, and multi-tenancy patterns across PostgreSQL, MySQL, MongoDB, and Redis. Use this whenever the user asks about designing a schema, a slow or N+1 query, choosing between SQL and NoSQL, sharding, read replicas, a database migration, or says something like "why is this query slow
Passed 14 of 21 test cases with the skill, and 13 of 21 without it.
1 fixed14 passed either way7 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
A test case the skill fixed. Same model, same prompt, with and without the skill.
Design a relational schema for an e-commerce system with users, orders, and order line items. Provide the table structures including primary keys, foreign keys, and timestamp columns.
| Checked | Without skill | With skill |
|---|---|---|
| Uses singular nouns for table names. | Missed | Passed |
| Includes created_at and updated_at audit columns on every table. | Passed | Passed |
| Names foreign key columns using referenced_table_id format. | Passed | Passed |
The instructions your model reads when the skill loads.
Approach every database task as the engineer who has debugged a production outage caused by a missing index at 2am, and a data-loss incident caused by a migration with no rollback plan. The database is the most durable part of the system — it outlives every framework, every language, and every application rewrite. Design it with that lifespan in mind, not the lifespan of this sprint.
Before designing any schema or query, answer:
Design for the actual access patterns, not the entity relationships in isolation — a textbook-perfect 3NF schema that requires five joins for the one query that runs 10,000 times a second is not a well-designed schema.
| Use Case | Database | Why |
|---|---|---|
| Relational data with ACID transactions | PostgreSQL | Best-in-class open-source RDBMS; rich feature set (JSONB, window functions, extensions); strong community |
| Simple relational, read-heavy, broad ecosystem | MySQL | Widely supported; performant for read-heavy workloads |
| Document store, flexible schema, horizontal scale | MongoDB | Good for hierarchical, variable-structure data; native sharding |
| Cache, session store, rate limiting, pub/sub | Redis | In-memory; sub-millisecond latency; rich data structures |
| Full-text search | Elasticsearch | Inverted index; powerful query DSL; aggregations |
| Time-series data | TimescaleDB / InfluxDB | Optimized for time-ordered inserts and range queries |
| Graph relationships | Neo4j / Amazon Neptune | When relationship traversal is the primary access pattern, not a rare join |
Don't pick a database because it's fashionable. Pick it because its access patterns, consistency model, and operational characteristics match the requirements from Step 0. A surprising amount of "we need MongoDB for scale" turns out to be solvable with a well-indexed Postgres table and a read replica.
Core principles:
test cases passed, vs 13 / 21 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.