AgentStack
Browse Sign in
Browse Why AgentStack Sell Docs
Sign in
SKILL verified MIT Self-run

Database Design Patterns

skill-nickcrew-claude-cortex-database-design-patterns · by NickCrew

Database schema design patterns and optimization strategies for relational and NoSQL databases. Use when designing database schemas, optimizing query performance, or implementing data persistence layers at scale.

No reviews yet
0 installs
48 views
0.0% view→install

Install

$ agentstack add skill-nickcrew-claude-cortex-database-design-patterns

✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

View the full security report →

Verified badge

Passed review? Show it. Paste this badge into your README, it links to the public security report.

AgentStack Verified badge Links to your public security report.
[![AgentStack Verified](https://agentstack.voostack.com/badges/verified.svg)](https://agentstack.voostack.com/security/report/skill-nickcrew-claude-cortex-database-design-patterns)

Reliability & compatibility

Security review passed
0 installs to date
no reviews yet
2mo ago

Declared compatibility

Claude CodeClaude Desktop

Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.

Preview Execution monitoring

We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.

How agent discovery & health will work →
Are you the author of Database Design Patterns? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

Database Design Patterns

Expert guidance for designing scalable database schemas, optimizing query performance, and implementing robust data persistence layers across relational and NoSQL databases.

When to Use This Skill

  • Designing database schemas for new applications
  • Optimizing slow queries and database performance
  • Choosing between normalization and denormalization strategies
  • Implementing partitioning, sharding, or replication strategies
  • Migrating between database technologies (SQL to NoSQL or vice versa)
  • Designing for high availability and disaster recovery
  • Implementing caching strategies and read replicas
  • Scaling databases horizontally or vertically
  • Ensuring data consistency in distributed systems

Core Concepts

Data Modeling

Design schemas that reflect business domain, access patterns, and consistency requirements. Balance normalization (data integrity) with denormalization (read performance) based on workload characteristics.

ACID vs. BASE

  • ACID (Relational): Atomicity, Consistency, Isolation, Durability - strong guarantees
  • BASE (NoSQL): Basically Available, Soft state, Eventually consistent - flexibility

CAP Theorem

Distributed systems choose two of three: Consistency, Availability, Partition Tolerance.

Polyglot Persistence

Use the right database for each use case: PostgreSQL for transactions, MongoDB for documents, Redis for caching, Elasticsearch for search, Cassandra for time-series, Neo4j for graphs.

Quick Reference

| Task | Load reference | | --- | --- | | Core database principles (ACID, BASE, CAP) | skills/database-design-patterns/references/core-principles.md | | Schema patterns (normalization, star schema, documents) | skills/database-design-patterns/references/schema-design-patterns.md | | Index types and strategies (B-tree, hash, covering) | skills/database-design-patterns/references/indexing-strategies.md | | Partitioning and sharding approaches | skills/database-design-patterns/references/partitioning-patterns.md | | Replication modes (primary-replica, multi-leader) | skills/database-design-patterns/references/replication-patterns.md | | Query optimization and caching | skills/database-design-patterns/references/query-optimization.md |

Workflow

Phase 1: Requirements Analysis

  1. Identify access patterns (read-heavy vs. write-heavy)
  2. Determine consistency requirements (strong vs. eventual)
  3. Estimate data volume and growth rate
  4. Define SLA requirements (latency, availability)

Phase 2: Schema Design

  1. Model entities and relationships
  2. Choose normalization level based on workload
  3. Design for query patterns, not just storage
  4. Consider data distribution strategy (partitioning/sharding)

Phase 3: Performance Optimization

  1. Analyze query execution plans (EXPLAIN ANALYZE)
  2. Add indexes for frequent queries
  3. Implement caching where appropriate
  4. Configure connection pooling
  5. Monitor and iterate

Phase 4: Scaling Strategy

  1. Implement read replicas for read scaling
  2. Consider partitioning for large tables (>100M rows)
  3. Plan sharding strategy for horizontal scaling
  4. Design for high availability with replication

Common Mistakes

Over-normalization: Too many joins slow down reads. Denormalize for read-heavy workloads.

Missing indexes: Analyze query patterns and add indexes for frequent WHERE/JOIN columns.

Wrong index type: Use composite indexes with correct column order (equality first, then range).

Ignoring replication lag: Handle eventual consistency with read-your-writes pattern.

Poor partitioning key: Choose keys that distribute data evenly and align with query patterns.

N+1 queries: Use JOINs or batch loading instead of querying in loops.

Inefficient pagination: Use keyset pagination instead of OFFSET for large datasets.

Connection exhaustion: Implement connection pooling sized for your workload.

Best Practices

  1. Model for access patterns - Design schemas around how data will be queried
  2. Index strategically - Index frequently queried columns, avoid over-indexing
  3. Partition large tables - Use for tables >100M rows or time-series data
  4. Replicate for reads - Primary-replica for read scaling, multi-leader for geo-distribution
  5. Optimize queries - Analyze execution plans, avoid N+1, use proper pagination
  6. Cache hot data - Application-level caching with appropriate TTLs
  7. Pool connections - Size connection pools based on workload
  8. Monitor continuously - Track query performance, index usage, replication lag
  9. Plan for growth - Design for 3x current load
  10. Choose consistency wisely - Match consistency level to business requirements

Resources

Books:

  • "Designing Data-Intensive Applications" (Kleppmann)
  • "High Performance MySQL" (Schwartz)

Sites:

  • use-the-index-luke.com
  • PostgreSQL documentation
  • MongoDB documentation

Tools:

  • EXPLAIN ANALYZE
  • pgstatstatements
  • Percona Toolkit
  • pt-query-digest

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet, be the first.

Versions

  • v0.1.0 Imported from the upstream source.