achreftlili/architect/database-selection
architect/database-selection/SKILL.md
--- name: database-selection description: Use this skill whenever the architect subagent is asked to choose a database, compare database options, decide between SQL and NoSQL, design a data storage strategy, or recommend a database for a specific use case. Triggers on: "which database should we use", "SQL vs NoSQL", "choose a database", "data storage strategy", "what DB fits", "PostgreSQL vs MongoDB", "database for this use case", "how should we store this data". Always use this skill before rec
$ install --global
skillsauthnpx skillsauth add achreftlili/deep-dev-skills architect/database-selectionInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 25, 2026, 2:48 PM14.0s1 file scanned
SKILL.md
- name:
- database-selection
- description:
- Use this skill whenever the architect subagent is asked to choose a database, compare database options, decide between SQL and NoSQL, design a data storage strategy, or recommend a database for a specific use case. Triggers on: "which database should we use", "SQL vs NoSQL", "choose a database", "data storage strategy", "what DB fits", "PostgreSQL vs MongoDB", "database for this use case", "how should we store this data". Always use this skill before recommending any database — it ensures the decision is grounded in data access patterns, not hype.
- category:
- architect
- agent-type:
- architect
Database Selection Skill
Purpose
Choose the right database for the job by analyzing data access patterns first, then matching to the appropriate storage paradigm.
Step 1 — Analyze Data Access Patterns
Answer these questions before looking at any database:
- What is the read/write ratio? (read-heavy → optimize for reads; write-heavy → optimize for writes)
- What queries will be run? (simple key lookups? complex joins? full-text search? aggregations?)
- What is the data structure? (flat records? nested documents? relationships? graphs? time-series?)
- What consistency is required? (strong ACID? eventual? per-entity?)
- What is the scale? (GB? TB? PB? queries/sec?)
- What are the access patterns? (random access? sequential scans? range queries? geo queries?)
The access pattern determines the database type. Never choose a database before answering these.
Step 2 — Database Type Selection
Relational (SQL) — Default Choice
Use when:
- Data has clear relationships and structure
- Need ACID transactions (financial, medical, inventory)
- Complex queries with joins, aggregations, reporting
- Schema is relatively stable
Top choices: PostgreSQL (default), MySQL, CockroachDB (distributed)
PostgreSQL is the safe default for most applications. Only deviate with a clear reason.
Document Store
Use when:
- Data is hierarchical/nested and read together
- Schema varies significantly per record
- High write throughput with flexible structure
- No complex cross-document joins needed
Top choices: MongoDB, Firestore, DynamoDB (with document access patterns)
Avoid when: you frequently need to query across document fields or join documents
Key-Value Store
Use when:
- Simple lookups by a known key
- Session storage, caching, feature flags
- Extremely high throughput, low latency requirements
- Data has no relationships
Top choices: Redis (in-memory), DynamoDB (persistent), Memcached (pure cache)
Wide-Column Store
Use when:
- Massive scale (billions of rows)
- High write throughput with time-series or event data
- Known, predictable query patterns (no ad-hoc queries)
- Need geographic distribution
Top choices: Cassandra, HBase, Bigtable
Search Engine
Use when:
- Full-text search with ranking/relevance
- Faceted filtering (e-commerce, catalogs)
- Log analysis and observability
Top choices: Elasticsearch, OpenSearch, Typesense (simpler), Meilisearch
Note: search engines are usually a secondary store — primary data lives in SQL/document DB
Graph Database
Use when:
- Data is fundamentally relational with many hops (social graphs, fraud detection, recommendations)
- Query patterns traverse relationships: "friends of friends who also bought X"
Top choices: Neo4j, Neptune (AWS), Memgraph
Time-Series Database
Use when:
- Data is timestamped and queried by time range
- Metrics, IoT sensor data, financial tick data
- High ingest rate with time-based aggregations
Top choices: InfluxDB, TimescaleDB (Postgres extension), Prometheus (metrics only)
Step 3 — Comparison Output Format
Always present the recommendation as:
Recommended: [Database]
- Why: [2–3 specific reasons tied to the access patterns identified]
- Schema sketch: show the main tables/collections/keys
- Indexing strategy: which fields to index and why
- Scaling approach: how it scales as data grows
Runner-up: [Database]
- Would choose if: [specific condition that would flip the decision]
Multi-Database Architectures
It is normal and correct to use multiple databases. Common patterns:
| Primary Store | Secondary Store | Purpose | |--------------|----------------|---------| | PostgreSQL | Redis | Caching hot reads | | PostgreSQL | Elasticsearch | Full-text search | | MongoDB | PostgreSQL | Reporting/analytics | | Any | S3/Blob storage | File/blob storage |
State the primary store first, then justify each additional store separately.
Decision Checklist
- [ ] Access patterns analyzed before choosing
- [ ] Consistency requirements defined (ACID vs eventual)
- [ ] Scale target stated (GB/TB, queries/sec)
- [ ] Backup and disaster recovery approach addressed
- [ ] Migration strategy from any existing database considered
- [ ] Team familiarity with chosen database assessed
- [ ] Managed service vs. self-hosted decision made
Related Skills
achreftlili/vitest-testing-skill
testing
VerifiedTrustedCommunity
Set up Vitest 2.x with TypeScript for unit and component testing using test/describe/it, vi.fn/vi.mock/vi.spyOn, component testing with Testing Library, coverage (v8/istanbul), workspace config, and snapshot testing.
1SKILL.mdUpdated Apr 25, 2026
achreftlili/pytest-testing-skill
testing
VerifiedTrustedCommunity
Set up pytest 8.x with Python for unit and integration testing using fixtures (scope, autouse, parametrize), async tests (pytest-asyncio), mocking (unittest.mock, pytest-mock), coverage (pytest-cov), conftest.py patterns, and markers.
1SKILL.mdUpdated Apr 25, 2026
achreftlili/playwright-testing-skill
testing
VerifiedTrustedCommunity
Set up Playwright 1.49+ with TypeScript for E2E testing using page object model, fixtures, test.describe/test blocks, assertions, selectors, network mocking, CI configuration, and trace viewer.
1SKILL.mdUpdated Apr 25, 2026
achreftlili/jest-testing-skill
testing
VerifiedTrustedCommunity
Set up Jest 30+ with TypeScript for unit tests, integration tests, mocking (jest.fn, jest.mock, jest.spyOn), coverage configuration, custom matchers, snapshot testing, and setup/teardown patterns.
1SKILL.mdUpdated Apr 25, 2026