operational-datastore-selection-relational-and-nosql
starsforks
How to install operational-datastore-selection-relational-and-nosql?
vaquarkhan/data-engineering-agent-skills/operational-datastore-selection-relational-and-nosql
$npx -y skills add vaquarkhan/data-engineering-agent-skills --skill operational-datastore-selection-relational-and-nosqlGuides agents through choosing relational operational stores such as MySQL versus NoSQL options such as document, key-value, wide-column, or cache-backed systems. Use when deciding where application-adjacent or pipeline-adjacent operational data should live.
SKILL.md
| 1 | # Operational Datastore Selection Relational And NoSQL |
| 2 | |
| 3 | ## Overview |
| 4 | |
| 5 | Use this skill when the real decision is not warehouse modeling, but what operational datastore should hold state, serve requests, or back data-driven application flows. It helps agents choose intentionally between relational systems such as `MySQL` and `PostgreSQL` versus `NoSQL` families such as document, key-value, wide-column, or cache-oriented stores. |
| 6 | |
| 7 | ## When to Use |
| 8 | |
| 9 | - choosing `MySQL` versus `NoSQL` for application-facing or service-facing data |
| 10 | - selecting stores for metadata, idempotency keys, session state, event state, or operational APIs |
| 11 | - deciding whether flexible schema or strict relational constraints matter more |
| 12 | - evaluating consistency, scale, and access-pattern trade-offs |
| 13 | - preventing analytics or pipeline systems from being misused as OLTP stores |
| 14 | |
| 15 | Do not treat datastore selection as a brand preference or trend decision. |
| 16 | |
| 17 | ## Workflow |
| 18 | |
| 19 | 1. Define the access pattern first. |
| 20 | Clarify: |
| 21 | - read versus write ratio |
| 22 | - request latency expectations |
| 23 | - query shapes |
| 24 | - update frequency |
| 25 | - retention and archival behavior |
| 26 | |
| 27 | 2. Define integrity and consistency needs. |
| 28 | Include: |
| 29 | - transactions |
| 30 | - joins and relational constraints |
| 31 | - uniqueness guarantees |
| 32 | - conflict handling |
| 33 | - tolerance for eventual consistency |
| 34 | |
| 35 | 3. Match the workload to the right store family. |
| 36 | Common guidance: |
| 37 | - relational stores such as `MySQL` fit well when transactions, constraints, and predictable relational queries matter |
| 38 | - document stores fit when entity shapes vary and document-oriented retrieval dominates |
| 39 | - key-value stores fit when lookup by key is primary and access patterns are narrow |
| 40 | - wide-column stores fit when scale and partition-oriented access dominate |
| 41 | - caches should accelerate another source of truth, not silently replace one |
| 42 | |
| 43 | 4. Check downstream and operational impact. |
| 44 | Consider: |
| 45 | - CDC and replication support |
| 46 | - backup and restore behavior |
| 47 | - schema evolution pain |
| 48 | - observability and operational maturity |
| 49 | - how analytics or warehouse ingestion will work |
| 50 | |
| 51 | 5. Record the trade-off explicitly. |
| 52 | A good decision names what the chosen store is not good at. |
| 53 | |
| 54 | ## Common Rationalizations |
| 55 | |
| 56 | | Rationalization | Reality | |
| 57 | | --- | --- | |
| 58 | | "NoSQL scales better, so we should use it." | Scale is only one axis; transactions, operability, and query ergonomics still matter. | |
| 59 | | "`MySQL` is too old-fashioned for modern systems." | Mature relational systems remain strong choices when consistency and relational integrity are central. | |
| 60 | | "The schema changes a lot, so we need schemaless storage." | Frequent shape change often signals unclear contracts, not necessarily a datastore requirement. | |
| 61 | |
| 62 | ## Red Flags |
| 63 | |
| 64 | - a warehouse or lakehouse is being used like an operational key-value store |
| 65 | - `NoSQL` is chosen with no explicit access-pattern justification |
| 66 | - relational transactions are required but omitted from the design |
| 67 | - a cache is treated as the only source of truth |
| 68 | - CDC, backup, or migration behavior is unknown |
| 69 | |
| 70 | ## Verification |
| 71 | |
| 72 | - [ ] Access patterns and latency needs are explicit |
| 73 | - [ ] Integrity and consistency requirements are named |
| 74 | - [ ] The chosen store family matches the actual workload |
| 75 | - [ ] CDC, backup, migration, and analytics implications are understood |
| 76 | - [ ] Trade-offs and non-goals are documented |
People who liked this also viewed
6 picksType
- azure-storageAzure Storage Services including Blob Storage, File Shares, Queue Storage, Table Storage, and Data Lake. Answers questions about storage access tiers (hot, cool, cold, archive), when to use each tier,SkillsJul 2026
- supabase-postgres-best-practicesPostgres performance optimization and best practices from Supabase. Use this skill when writing, reviewing, or optimizing Postgres queries, schema designs, or database configurations.SkillsJul 2026
- supabaseUse when doing ANY task involving Supabase. Triggers: Supabase products (Database, Auth, Edge Functions, Realtime, Storage, Vectors, Cron, Queues); client libraries and SSR integrations (supabase-js, SkillsJul 2026
- convex-quickstartCreates or adds Convex to an app. Use for new Convex projects, npm create convex@latest, frontend setup, env vars, or the first npx convex dev run.SkillsJul 2026
- convex-performance-auditAudits Convex performance for reads, subscriptions, write contention, and function limits. Use for slow features, insights findings, OCC conflicts, or read amplification.SkillsJul 2026
- convex-setup-authSets up Convex auth, identity mapping, and access control. Use for login, auth providers, users tables, protected functions, or roles in a Convex app.SkillsJul 2026
