
Nosql Database Design
- 436 installs
- 305 repo stars
- Updated March 4, 2026
- aj-geddes/useful-ai-prompts
nosql-database-design is a Claude Code skill that designs NoSQL schemas, partition keys, indexes, and access patterns for document, key-value, and wide-column stores for developers building scalable read and write paths
About
nosql-database-design is a prompt-driven skill from aj-geddes/useful-ai-prompts that guides schema design for document, key-value, and wide-column NoSQL databases. The skill helps developers choose partition keys, secondary indexes, and query access patterns that avoid hot partitions and support predictable read/write throughput on DynamoDB, MongoDB, Cassandra, and similar stores. Reach for nosql-database-design when modeling multi-tenant SaaS data or high-volume API backends where relational normalization is a poor fit and access-pattern-first design is required. Output includes partition key recommendations, index plans, entity relationship sketches, and query pattern tables developers can implement in Terraform, CloudFormation, or ORM migration files.
- Access-pattern-first schema modeling
- Partition key and shard strategy guidance
- Index design for hot query paths
- Consistency and denormalization tradeoff framing
- Migration and evolution patterns for document stores
Nosql Database Design by the numbers
- 436 all-time installs (skills.sh)
- Ranked #135 of 911 Databases skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/aj-geddes/useful-ai-prompts --skill nosql-database-designAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 436 |
|---|---|
| repo stars | ★ 305 |
| Last updated | March 4, 2026 |
| Repository | aj-geddes/useful-ai-prompts ↗ |
How do you design NoSQL schemas and partition keys?
Design NoSQL schemas, partition keys, indexes, and access patterns for document, key-value, or wide-column stores when building scalable read/write paths for apps and APIs.
Who is it for?
Backend engineers modeling DynamoDB, MongoDB, or Cassandra data layers with access-pattern-first design.
Skip if: Relational PostgreSQL schema design or simple CRUD apps where a single-table SQL model suffices.
When should I use this skill?
User asks to design NoSQL schema, partition keys, DynamoDB access patterns, or document store indexes.
What you get
NoSQL schema with partition keys, indexes, access patterns, and entity model
Files
NoSQL Database Design
Table of Contents
Overview
Design scalable NoSQL schemas for MongoDB (document) and DynamoDB (key-value). Covers data modeling patterns, denormalization strategies, and query optimization for NoSQL systems.
When to Use
- MongoDB collection design
- DynamoDB table and index design
- Document structure modeling
- Embedding vs. referencing decisions
- Query pattern optimization
- NoSQL indexing strategies
- Data denormalization planning
Quick Start
Minimal working example:
// Single document with embedded arrays
db.createCollection("users");
db.users.insertOne({
_id: ObjectId("..."),
email: "john@example.com",
name: "John Doe",
createdAt: new Date(),
// Embedded address
address: {
street: "123 Main St",
city: "New York",
state: "NY",
zipCode: "10001",
},
// Embedded array of items
orders: [
{
orderId: ObjectId("..."),
date: new Date(),
total: 149.99,
},
{
// ... (see reference guides for full implementation)Reference Guides
Detailed implementations in the references/ directory:
| Guide | Contents |
|---|---|
| Document Structure Design | Document Structure Design |
| Indexing in MongoDB | Indexing in MongoDB |
| Schema Validation | Schema Validation |
| Table Structure | Table Structure |
| Global Secondary Indexes (GSI) | Global Secondary Indexes (GSI) |
| DynamoDB Item Operations | DynamoDB Item Operations |
Best Practices
✅ DO
- Follow established patterns and conventions
- Write clean, maintainable code
- Add appropriate documentation
- Test thoroughly before deploying
❌ DON'T
- Skip testing or validation
- Ignore error handling
- Hard-code configuration values
Document Structure Design
Document Structure Design
MongoDB - Embedded Documents:
// Single document with embedded arrays
db.createCollection("users");
db.users.insertOne({
_id: ObjectId("..."),
email: "john@example.com",
name: "John Doe",
createdAt: new Date(),
// Embedded address
address: {
street: "123 Main St",
city: "New York",
state: "NY",
zipCode: "10001",
},
// Embedded array of items
orders: [
{
orderId: ObjectId("..."),
date: new Date(),
total: 149.99,
},
{
orderId: ObjectId("..."),
date: new Date(),
total: 89.99,
},
],
});MongoDB - Referenced Documents:
// Separate collections with references
db.createCollection("users");
db.createCollection("orders");
db.users.insertOne({
_id: ObjectId("..."),
email: "john@example.com",
name: "John Doe",
});
db.orders.insertMany([
{
_id: ObjectId("..."),
userId: ObjectId("..."), // Reference to user
orderDate: new Date(),
total: 149.99,
},
{
_id: ObjectId("..."),
userId: ObjectId("..."),
orderDate: new Date(),
total: 89.99,
},
]);
// Query with $lookup for JOINs
db.orders.aggregate([
{
$match: { userId: ObjectId("...") },
},
{
$lookup: {
from: "users",
localField: "userId",
foreignField: "_id",
as: "user",
},
},
]);DynamoDB Item Operations
DynamoDB Item Operations
// Put item (insert/update)
const putParams = {
TableName: "users",
Item: {
userId: { S: "user-123" },
email: { S: "john@example.com" },
name: { S: "John Doe" },
createdAt: { N: Date.now().toString() },
metadata: {
M: {
joinDate: { N: Date.now().toString() },
source: { S: "web" },
},
},
},
};
// Query using GSI
const queryParams = {
TableName: "users",
IndexName: "emailIndex",
KeyConditionExpression: "email = :email",
ExpressionAttributeValues: {
":email": { S: "john@example.com" },
},
};
// Batch get items
const batchGetParams = {
RequestItems: {
users: {
Keys: [{ userId: { S: "user-123" } }, { userId: { S: "user-456" } }],
},
},
};Global Secondary Indexes (GSI)
Global Secondary Indexes (GSI)
// Add GSI for querying by email
const gsiParams = {
TableName: "users",
AttributeDefinitions: [{ AttributeName: "email", AttributeType: "S" }],
GlobalSecondaryIndexes: [
{
IndexName: "emailIndex",
KeySchema: [{ AttributeName: "email", KeyType: "HASH" }],
Projection: {
ProjectionType: "ALL", // Return all attributes
},
BillingMode: "PAY_PER_REQUEST",
},
],
};
// GSI with composite key for time-based queries
const timeIndexParams = {
GlobalSecondaryIndexes: [
{
IndexName: "userCreatedIndex",
KeySchema: [
{ AttributeName: "userId", KeyType: "HASH" },
{ AttributeName: "createdAt", KeyType: "RANGE" },
],
Projection: { ProjectionType: "ALL" },
BillingMode: "PAY_PER_REQUEST",
},
],
};Indexing in MongoDB
Indexing in MongoDB
// Single field index
db.users.createIndex({ email: 1 });
db.orders.createIndex({ createdAt: -1 });
// Compound index
db.orders.createIndex({ userId: 1, createdAt: -1 });
// Text index for search
db.products.createIndex({ name: "text", description: "text" });
// Geospatial index
db.stores.createIndex({ location: "2dsphere" });
// TTL index for auto-expiration
db.sessions.createIndex({ createdAt: 1 }, { expireAfterSeconds: 3600 });
// Sparse index (only documents with field)
db.users.createIndex({ phone: 1 }, { sparse: true });
// Check index usage
db.users.aggregate([{ $indexStats: {} }]);Schema Validation
Schema Validation
// Define collection validation schema
db.createCollection("products", {
validator: {
$jsonSchema: {
bsonType: "object",
required: ["name", "price", "category"],
properties: {
_id: { bsonType: "objectId" },
name: {
bsonType: "string",
description: "Product name (required)",
},
price: {
bsonType: "decimal",
minimum: 0,
description: "Price must be positive",
},
category: {
enum: ["electronics", "clothing", "food"],
description: "Category must be one of listed values",
},
tags: {
bsonType: "array",
items: { bsonType: "string" },
},
createdAt: {
bsonType: "date",
},
},
},
},
});Table Structure
Table Structure
// DynamoDB table with single primary key
const TableName = "users";
const params = {
TableName,
KeySchema: [
{ AttributeName: "userId", KeyType: "HASH" }, // Partition key
],
AttributeDefinitions: [
{ AttributeName: "userId", AttributeType: "S" }, // String
],
BillingMode: "PAY_PER_REQUEST", // On-demand
};
// DynamoDB table with composite primary key
const ordersParams = {
TableName: "orders",
KeySchema: [
{ AttributeName: "userId", KeyType: "HASH" }, // Partition key
{ AttributeName: "orderId", KeyType: "RANGE" }, // Sort key
],
AttributeDefinitions: [
{ AttributeName: "userId", AttributeType: "S" },
{ AttributeName: "orderId", AttributeType: "S" },
],
BillingMode: "PAY_PER_REQUEST",
};#!/bin/bash
# validate-schema.sh - Validate database schema
# Usage: ./validate-schema.sh <schema_file>
set -euo pipefail
SCHEMA_FILE="${{1:?Usage: $0 <schema_file>}}"
echo "Validating schema: $SCHEMA_FILE"
# TODO: Add schema validation
# - Check SQL syntax
# - Verify foreign key references
# - Check index definitions
# - Validate naming conventions
# - Check for missing constraints
echo "Schema validation complete."
-- Migration: [description]
-- Created: [date]
-- TODO: Customize for your migration framework
BEGIN;
-- Up migration
-- TODO: Add schema changes
-- CREATE TABLE IF NOT EXISTS ...
-- ALTER TABLE ...
-- Down migration (rollback)
-- TODO: Add rollback statements
-- DROP TABLE IF EXISTS ...
COMMIT;
Related skills
How it compares
Pick nosql-database-design for access-pattern-first NoSQL modeling; use relational migration skills when PostgreSQL normalization is the right fit.
FAQ
Which NoSQL stores does nosql-database-design cover?
nosql-database-design covers document, key-value, and wide-column stores such as DynamoDB, MongoDB, and Cassandra. The skill focuses on partition keys, indexes, and access-pattern-first modeling for scalable API read and write paths.
What artifacts does nosql-database-design produce?
nosql-database-design produces partition key recommendations, secondary index plans, entity relationship sketches, and query access-pattern tables. Developers can translate output into Terraform table definitions, migration files, or ORM models.