When to Use SQL vs NoSQL Databases: A Comprehensive 2026 Guide

-- Users table
CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    email VARCHAR(255) UNIQUE NOT NULL,
    name VARCHAR(100) NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- Orders table with foreign key relationship
CREATE TABLE orders (
    id SERIAL PRIMARY KEY,
    user_id INTEGER NOT NULL REFERENCES users(id),
    total_amount DECIMAL(10, 2) NOT NULL,
    status VARCHAR(20) NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- Query with JOIN
SELECT users.name, orders.total_amount
FROM users
JOIN orders ON users.id = orders.user_id
WHERE orders.status = 'completed';

BEGIN TRANSACTION;

-- Deduct from sender
UPDATE accounts SET balance = balance - 100 WHERE id = 1;

-- Add to receiver
UPDATE accounts SET balance = balance + 100 WHERE id = 2;

-- If anything fails, both operations roll back
COMMIT;

-- Complex join query
SELECT 
    customers.name,
    COUNT(orders.id) as order_count,
    SUM(order_items.quantity * order_items.price) as total_spent
FROM customers
JOIN orders ON customers.id = orders.customer_id
JOIN order_items ON orders.id = order_items.order_id
GROUP BY customers.id
HAVING total_spent > 1000
ORDER BY total_spent DESC;

-- Schema with constraints
CREATE TABLE products (
    id SERIAL PRIMARY KEY,
    name VARCHAR(200) NOT NULL,
    price DECIMAL(10, 2) CHECK (price > 0),
    stock INTEGER CHECK (stock >= 0),
    category_id INTEGER REFERENCES categories(id)
);

-- Invalid data is rejected
INSERT INTO products (name, price) 
VALUES ('Product', -10); -- Error: price must be > 0

{
  "_id": ObjectId("507f1f77bcf86cd799439011"),
  "name": "John Doe",
  "email": "john@example.com",
  "addresses": [
    {
      "type": "home",
      "street": "123 Main St",
      "city": "New York"
    }
  ],
  "orders": [
    {
      "orderId": "ORD-001",
      "total": 99.99,
      "items": [
        { "product": "Laptop", "quantity": 1, "price": 99.99 }
      ]
    }
  ]
}

// Set and get values
SET user:1000:name "John Doe"
GET user:1000:name // Returns "John Doe"

// Hash for structured data
HSET user:1000 name "John" email "john@example.com" age 30

// Lists
LPUSH notifications "New message"

// Sets
SADD interests "tech" "sports"

// Sorted sets (leaderboards)
ZADD leaderboard 1500 "player1"
ZREVRANGE leaderboard 0 9 // Top 10

CREATE TABLE sensor_data (
    sensor_id uuid,
    timestamp timestamp,
    temperature decimal,
    humidity decimal,
    PRIMARY KEY (sensor_id, timestamp)
) WITH CLUSTERING ORDER BY (timestamp DESC);

-- Excellent for time-series data
SELECT * FROM sensor_data 
WHERE sensor_id = ? AND timestamp > ?;

// Create relationships
CREATE (john:Person {name: 'John'})-[:FRIENDS_WITH]->(alice:Person {name: 'Alice'})
CREATE (john)-[:WORKS_FOR]->(company:Company {name: 'TechCorp'})

// Query relationships
MATCH (john:Person {name: 'John'})-[:FRIENDS_WITH]->(friend)-[:PURCHASED]->(product)
WHERE NOT (john)-[:PURCHASED]->(product)
RETURN product.name

// MongoDB - Different structures in same collection

// Document 1 (old format)
{
  "_id": 1,
  "name": "John",
  "email": "john@example.com"
}

// Document 2 (new format)
{
  "_id": 2,
  "name": "Jane",
  "email": "jane@example.com",
  "phone": "+1234567890",
  "preferences": { "theme": "dark" },
  "verified": true
}

// No migration needed - application handles both

// MongoDB automatic sharding
sh.enableSharding("mydb")
sh.shardCollection("mydb.users", {user_id: "hashed"})

// Data automatically distributed across servers
// System handles:
// - Data distribution
// - Query routing
// - Replication
// - Failover

// SQL approach (normalized) - Multiple tables with joins
// users, orders, order_items

// NoSQL approach (denormalized) - Embedded data
{
  "userId": "123",
  "name": "John",
  "orders": [
    {
      "orderId": "ORD-001",
      "items": [
        { "product": "Laptop", "quantity": 1, "price": 999.99 }
      ]
    }
  ]
}

// Single query retrieves everything - no joins!

-- Three separate tables
Table: users
id | name      | email
1  | John Doe  | john@example.com

Table: orders  
id | user_id | total | date
1  | 1       | 99.99 | 2026-01-15

Table: order_items
id | order_id | product    | quantity
1  | 1        | Laptop     | 1

-- Query requires JOIN
SELECT u.name, o.total, oi.product
FROM users u
JOIN orders o ON u.id = o.user_id
JOIN order_items oi ON o.id = oi.order_id;

// Single document
{
  "userId": 1,
  "name": "John Doe",
  "email": "john@example.com",
  "orders": [
    {
      "orderId": 1,
      "total": 99.99,
      "date": "2026-01-15",
      "items": [
        { "product": "Laptop", "quantity": 1 }
      ]
    }
  ]
}

// Single query retrieves everything
db.users.findOne({userId: 1})

Challenge: Limited by single server capacity

Initial:     4 cores, 16 GB RAM
Scale up:    16 cores, 128 GB RAM
Maximum:     64 cores, 512 GB RAM

Issues:
- Expensive at high end
- Hardware limits
- Single point of failure

Add more servers as needed

Initial:     3 servers (1TB each)
Scale out:   6 servers (2TB total distributed)
Further:     12 servers (4TB total distributed)

Benefits:
- Linear cost scaling
- No theoretical limit
- Built-in redundancy

-- E-commerce example with multiple relationships
SELECT 
    customers.name,
    products.name as product,
    categories.name as category,
    SUM(order_items.quantity) as total_purchased,
    AVG(reviews.rating) as avg_rating
FROM customers
JOIN orders ON customers.id = orders.customer_id
JOIN order_items ON orders.id = order_items.order_id
JOIN products ON order_items.product_id = products.id
JOIN categories ON products.category_id = categories.id
LEFT JOIN reviews ON products.id = reviews.product_id
GROUP BY customers.id, products.id, categories.id
HAVING AVG(reviews.rating) > 4.0;

-- Banking transaction (must be consistent)
BEGIN TRANSACTION;

UPDATE accounts SET balance = balance - 1000 
WHERE account_id = 'A123' AND balance >= 1000;

UPDATE accounts SET balance = balance + 1000 
WHERE account_id = 'B456';

-- If sender has insufficient funds, both operations roll back
COMMIT;

-- Order processing with inventory
BEGIN TRANSACTION;

-- Create order
INSERT INTO orders (customer_id, total) VALUES (123, 99.99);

-- Add order items
INSERT INTO order_items (order_id, product_id, quantity) VALUES (LAST_INSERT_ID(), 456, 2);

-- Update inventory
UPDATE products SET stock = stock - 2 WHERE id = 456 AND stock >= 2;

-- If any step fails, everything rolls back
COMMIT;

-- Complex analytical query
WITH monthly_sales AS (
    SELECT 
        DATE_TRUNC('month', order_date) as month,
        product_id,
        SUM(quantity * price) as revenue
    FROM order_items
    GROUP BY DATE_TRUNC('month', order_date), product_id
),
product_rankings AS (
    SELECT 
        month,
        product_id,
        revenue,
        RANK() OVER (PARTITION BY month ORDER BY revenue DESC) as rank
    FROM monthly_sales
)
SELECT 
    p.name,
    pr.month,
    pr.revenue,
    pr.rank
FROM product_rankings pr
JOIN products p ON pr.product_id = p.id
WHERE pr.rank <= 10
ORDER BY pr.month DESC, pr.rank;

// Start with basic user
{
  "userId": 1,
  "name": "John",
  "email": "john@example.com"
}

// Add new fields without migration
{
  "userId": 2,
  "name": "Jane",
  "email": "jane@example.com",
  "phone": "+1234567890",
  "socialProfiles": {
    "twitter": "@jane",
    "linkedin": "jane-doe"
  },
  "preferences": {
    "newsletter": true,
    "theme": "dark"
  },
  "tags": ["premium", "early-adopter"]
}

// Application handles both gracefully - no downtime

// MongoDB: 100,000+ inserts/second
for (let i = 0; i < 100000; i++) {
  db.events.insertOne({
    userId: randomUser(),
    event: "page_view",
    timestamp: new Date(),
    metadata: { page: "/home", duration: 1500 }
  });
}

// Redis: 100,000+ operations/second
for (let i = 0; i < 100000; i++) {
  redis.set(`session:${i}`, JSON.stringify(sessionData));
}

// Cassandra: 1,000,000+ writes/second (distributed cluster)

// Automatic sharding in MongoDB
sh.shardCollection("app.users", { userId: "hashed" })

// System automatically:
// - Distributes data across shards
// - Routes queries to correct shards
// - Rebalances data when adding servers
// - Handles failover

// Add capacity by adding servers (linear scaling)
// Server 1 + Server 2 + Server 3 = 3x capacity
// Server 1 + Server 2 + ... + Server 10 = 10x capacity

// Product catalog with varying attributes
{
  "productId": "LAPTOP-001",
  "category": "electronics",
  "name": "Gaming Laptop",
  "specs": {
    "cpu": "Intel i9",
    "ram": "32GB",
    "gpu": "RTX 4080",
    "storage": "2TB SSD"
  }
}

{
  "productId": "SHIRT-001",
  "category": "clothing",
  "name": "T-Shirt",
  "specs": {
    "size": "L",
    "color": "Blue",
    "material": "Cotton"
  }
}

// Different products have completely different attributes
// SQL would require multiple tables or JSON columns
// NoSQL handles naturally

// Common NoSQL patterns (fast and simple)

// 1. Get by ID
const user = await db.users.findOne({ userId: 123 });

// 2. Get by single field
const user = await db.users.findOne({ email: "john@example.com" });

// 3. Range queries
const recentOrders = await db.orders.find({
  userId: 123,
  createdAt: { $gte: new Date("2026-01-01") }
});

// 4. Simple aggregation
const stats = await db.orders.aggregate([
  { $match: { userId: 123 } },
  { $group: { _id: null, total: { $sum: "$amount" } } }
]);

// Avoid NoSQL if you need:
// - Complex multi-document joins
// - Cross-collection transactions
// - Sophisticated aggregations

// Day 1: Simple user model
{
  "name": "John",
  "email": "john@example.com"
}

// Day 5: Add features without migration
{
  "name": "John",
  "email": "john@example.com",
  "avatar": "https://...",
  "bio": "Developer"
}

// Day 10: Add more features
{
  "name": "John",
  "email": "john@example.com",
  "avatar": "https://...",
  "bio": "Developer",
  "skills": ["JavaScript", "Python"],
  "experience": [
    { "company": "TechCorp", "years": 3 }
  ]
}

// No ALTER TABLE statements
// No migration scripts
// No downtime

// Session storage (Redis)
await redis.setex(`session:${sessionId}`, 3600, JSON.stringify({
  userId: 123,
  loginTime: Date.now(),
  preferences: { theme: "dark" }
}));

// Cache expensive query results
const cacheKey = `user:${userId}:profile`;
let profile = await redis.get(cacheKey);

if (!profile) {
  profile = await db.users.findOne({ userId });
  await redis.setex(cacheKey, 300, JSON.stringify(profile));
}

// Rate limiting
const requestCount = await redis.incr(`ratelimit:${userId}`);
if (requestCount === 1) {
  await redis.expire(`ratelimit:${userId}`, 60);
}
if (requestCount > 100) {
  throw new Error("Rate limit exceeded");
}

// Cassandra for time-series data
CREATE TABLE sensor_readings (
    sensor_id uuid,
    reading_time timestamp,
    temperature decimal,
    humidity decimal,
    pressure decimal,
    PRIMARY KEY (sensor_id, reading_time)
) WITH CLUSTERING ORDER BY (reading_time DESC);

// Efficient queries by time range
SELECT * FROM sensor_readings
WHERE sensor_id = ? 
  AND reading_time >= '2026-01-01'
  AND reading_time < '2026-02-01';

// InfluxDB for metrics
from(bucket: "metrics")
  |> range(start: -1h)
  |> filter(fn: (r) => r._measurement == "cpu_usage")
  |> aggregateWindow(every: 1m, fn: mean)

-- Critical transactional data
Tables:
- users (authentication, billing)
- orders (order records)
- payments (payment transactions)
- inventory (stock management)

-- Why SQL:
-- - ACID transactions for payments
-- - Inventory consistency
-- - Complex order reports
-- - Financial compliance

// Flexible, high-volume data
Collections:
- product_catalog (varying attributes)
- user_sessions (temporary data)
- product_reviews (unstructured content)
- browsing_history (high write volume)

// Why NoSQL:
// - Products have different attributes
// - High write volume for analytics
// - Flexible schema for reviews
// - Fast product searches

// Real-time, high-performance data
- shopping_carts (temporary, fast access)
- product_recommendations (computed data)
- session_management (expiring data)
- rate_limiting (API protection)

// Why Redis:
// - Sub-millisecond latency
// - Automatic expiration
// - High throughput
// - In-memory performance

// MongoDB for social features
{
  "userId": "123",
  "username": "johndoe",
  "posts": [
    {
      "postId": "abc",
      "content": "Hello world!",
      "timestamp": ISODate("2026-01-15"),
      "likes": 150,
      "comments": [
        {
          "userId": "456",
          "text": "Great post!",
          "timestamp": ISODate("2026-01-15")
        }
      ]
    }
  ],
  "followers": ["456", "789"],
  "following": ["456"]
}

// Why NoSQL:
// - Massive scale (millions of posts/day)
// - Flexible post formats (text, images, videos)
// - Denormalized for fast reads
// - Horizontal scaling essential

// Social graph and recommendations
MATCH (user:Person {id: "123"})-[:FOLLOWS]->(friend)-[:FOLLOWS]->(suggestion)
WHERE NOT (user)-[:FOLLOWS]->(suggestion)
  AND user <> suggestion
RETURN suggestion.name, COUNT(friend) as mutual_friends
ORDER BY mutual_friends DESC
LIMIT 10;

// Why Graph:
// - Complex relationship queries
// - Friend recommendations
// - Network analysis
// - Influencer detection

-- Business-critical data
Tables:
- user_accounts (authentication)
- payments (subscriptions)
- analytics (aggregated metrics)

-- Why SQL:
-- - Financial transactions
-- - Compliance requirements
-- - Accurate billing

-- Core banking operations
CREATE TABLE accounts (
    account_id VARCHAR(20) PRIMARY KEY,
    customer_id INTEGER NOT NULL,
    balance DECIMAL(15, 2) NOT NULL CHECK (balance >= 0),
    account_type VARCHAR(20) NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE transactions (
    transaction_id SERIAL PRIMARY KEY,
    from_account VARCHAR(20) REFERENCES accounts(account_id),
    to_account VARCHAR(20) REFERENCES accounts(account_id),
    amount DECIMAL(15, 2) NOT NULL CHECK (amount > 0),
    transaction_type VARCHAR(20) NOT NULL,
    timestamp TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    status VARCHAR(20) NOT NULL
);

-- ACID transaction for money transfer
BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;

UPDATE accounts SET balance = balance - 1000.00
WHERE account_id = 'A123' AND balance >= 1000.00;

UPDATE accounts SET balance = balance + 1000.00
WHERE account_id = 'B456';

INSERT INTO transactions (from_account, to_account, amount, transaction_type, status)
VALUES ('A123', 'B456', 1000.00, 'transfer', 'completed');

COMMIT;

// Why SQL:
// - Absolute consistency required
// - Regulatory compliance
// - Audit trails
// - Complex reporting
// - Zero tolerance for data loss

// Supplementary systems
- Fraud detection (real-time analysis)
- User activity logs (high volume)
- Customer 360 view (aggregated data)

// Redis for:
- Real-time fraud scores
- Session management
- Rate limiting

-- Cassandra for sensor data
CREATE TABLE sensor_metrics (
    sensor_id uuid,
    metric_time timestamp,
    temperature decimal,
    humidity decimal,
    pressure decimal,
    battery_level decimal,
    PRIMARY KEY (sensor_id, metric_time)
) WITH CLUSTERING ORDER BY (metric_time DESC)
  AND compaction = {'class': 'TimeWindowCompactionStrategy'};

-- Optimized for:
-- - Millions of writes per second
-- - Time-range queries
-- - Automatic data retention
-- - Horizontal scaling

-- InfluxDB alternative
SELECT mean(temperature), max(temperature)
FROM sensor_data
WHERE time >= now() - 1h
GROUP BY time(1m), sensor_id;

// Why NoSQL:
// - Massive write throughput
// - Time-based queries
// - Automatic downsampling
// - Efficient storage

// Content storage
{
  "articleId": "article-123",
  "title": "Database Guide",
  "author": "John Doe",
  "content": "...",
  "metadata": {
    "category": "Technology",
    "tags": ["databases", "sql", "nosql"],
    "publishDate": ISODate("2026-01-15"),
    "status": "published"
  },
  "comments": [
    {
      "userId": "user-456",
      "text": "Great article!",
      "timestamp": ISODate("2026-01-16")
    }
  ],
  "analytics": {
    "views": 1500,
    "shares": 50
  }
}

// Why NoSQL:
// - Flexible content structure
// - Easy to add new fields
// - Fast content delivery
// - Embedded comments/metadata

-- Structured administrative data
Tables:
- users (CMS users)
- roles_permissions (access control)
- workflow (approval process)
- audit_logs (change tracking)

-- Why SQL:
-- - User management
-- - Permission checks
-- - Workflow enforcement
-- - Compliance

// Wrong reasoning:
"MongoDB is modern and cool, let's use it everywhere!"
"NoSQL is web-scale, SQL is outdated!"
"Everyone uses PostgreSQL, so we should too!"

// Right reasoning:
"Our data has complex relationships → SQL is better"
"We need to scale to millions of writes/sec → NoSQL fits"
"We need ACID guarantees for financial data → SQL required"

// Anti-pattern: Manual joins in application code
async function getUserWithOrders(userId) {
  const user = await db.users.findOne({ _id: userId });

  const orders = await db.orders.find({ userId: userId });

  for (let order of orders) {
    order.items = await db.orderItems.find({ orderId: order._id });

    for (let item of order.items) {
      item.product = await db.products.findOne({ _id: item.productId });
    }
  }

  user.orders = orders;
  return user;
}

// Multiple database queries (N+1 problem)
// Slow and inefficient

// Better: Denormalize and embed
{
  "userId": "123",
  "name": "John",
  "orders": [
    {
      "orderId": "ORD-001",
      "items": [
        {
          "productName": "Laptop",
          "price": 999.99,
          "quantity": 1
        }
      ]
    }
  ]
}

// Single query retrieves everything

// Bad NoSQL design (not optimized for access pattern)
{
  "orderId": "ORD-001",
  "customerId": "CUST-123",
  "items": [...]
}

// Frequent query: "Get all orders for a customer"
// Requires scanning entire collection or creating index

// Better design (partition by customer)
{
  "customerId": "CUST-123",
  "orders": [
    { "orderId": "ORD-001", "items": [...] },
    { "orderId": "ORD-002", "items": [...] }
  ]
}

// Single document retrieval by customerId

-- Frequent query pattern not considered
CREATE TABLE products (
    id SERIAL PRIMARY KEY,
    name VARCHAR(200),
    description TEXT,
    price DECIMAL(10, 2)
);

-- Query: "Find products by price range" (common query)
SELECT * FROM products WHERE price BETWEEN 100 AND 500;
-- Slow without index!

-- Solution: Add index for common query
CREATE INDEX idx_products_price ON products(price);

-- SQL: Difficult to change later
CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    full_name VARCHAR(100)
);

-- Later need to split name
-- Requires:
-- 1. Add new columns
-- 2. Migrate data
-- 3. Update application
-- 4. Remove old column
-- 5. Handle both formats during transition

ALTER TABLE users ADD COLUMN first_name VARCHAR(50);
ALTER TABLE users ADD COLUMN last_name VARCHAR(50);

UPDATE users SET 
    first_name = SPLIT_PART(full_name, ' ', 1),
    last_name = SPLIT_PART(full_name, ' ', 2);

-- Risky on large tables

// Premature optimization
"We might have 1 billion users, so let's use Cassandra cluster!"
// Actual users: 100

// Reality check:
// - PostgreSQL handles millions of rows easily
// - Start simple, scale when needed
// - Premature distributed systems = complexity without benefit

// Start with proven, simple solution
// PostgreSQL or MySQL for most use cases

// Scale when you actually need to:
// - Millions of requests/second
// - Petabytes of data
// - Global distribution required

// Monitor metrics and scale based on data, not speculation

// Bad: Using NoSQL with eventual consistency for inventory
async function purchaseProduct(productId, quantity) {
  const product = await db.products.findOne({ _id: productId });

  if (product.stock >= quantity) {
    // Update stock
    await db.products.updateOne(
      { _id: productId },
      { $inc: { stock: -quantity } }
    );

    // Race condition! Two requests can oversell
    // Eventual consistency means different nodes may have different stock values
  }
}

// Better: Use SQL with transactions or MongoDB with transactions
await session.withTransaction(async () => {
  const product = await db.products.findOne(
    { _id: productId },
    { session }
  );

  if (product.stock < quantity) {
    throw new Error("Insufficient stock");
  }

  await db.products.updateOne(
    { _id: productId },
    { $inc: { stock: -quantity } },
    { session }
  );
});

SQL databases: Choose CP (Consistency + Partition Tolerance)
- Strong consistency
- May be unavailable during network issues

NoSQL databases: Often choose AP (Availability + Partition Tolerance)
- Always available
- May have stale data

-- PostgreSQL-compatible syntax
CREATE TABLE users (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    email STRING UNIQUE NOT NULL,
    name STRING NOT NULL
);

-- Automatic horizontal scaling
-- ACID transactions across distributed nodes
-- Survives data center failures
-- Strong consistency

-- PostgreSQL-compatible
-- Distributed by default
-- Automatic failover
-- Multi-cloud deployment

-- Same SQL syntax, distributed architecture
SELECT * FROM orders WHERE customer_id = 123;
-- Query automatically routed to correct nodes

// Document storage
db.users.save({
  name: "John",
  email: "john@example.com"
});

// Graph queries
FOR v, e, p IN 1..3 OUTBOUND 'users/john' GRAPH 'social'
  RETURN p;

// Key-value operations
db._query(`
  FOR doc IN users
  FILTER doc._key == 'john'
  RETURN doc
`);

// Single database, multiple paradigms

-- Relational tables
CREATE TABLE users (id SERIAL PRIMARY KEY, name TEXT);

-- JSON documents
CREATE TABLE products (
    id SERIAL PRIMARY KEY,
    data JSONB
);

INSERT INTO products (data) VALUES ('{"name": "Laptop", "price": 999.99}');

-- Full-text search
CREATE INDEX idx_products_search ON products 
USING GIN(to_tsvector('english', data->>'name'));

-- Time-series (with TimescaleDB extension)
-- Graph queries (with Apache AGE extension)
-- Vector similarity (with pgvector extension)

// GraphQL-native, serverless
// No infrastructure management
// Global distribution
// ACID transactions

query GetUser($id: ID!) {
  findUserByID(id: $id) {
    name
    email
    orders {
      data {
        total
        items {
          product {
            name
          }
        }
      }
    }
  }
}

// Pricing: Pay per request
// No servers to manage
// Automatic scaling

-- MySQL-compatible
-- Vitess-powered (scales like NoSQL)
-- Branching (like Git for databases)
-- No downtime migrations

-- Create branch for schema changes
-- Test changes in isolation
-- Deploy with zero downtime

# Pinecone, Weaviate, Milvus
# Store and query vector embeddings

# Store document embeddings
index.upsert([
    ("doc1", [0.1, 0.2, 0.3, ...], {"text": "Database guide"}),
    ("doc2", [0.2, 0.3, 0.4, ...], {"text": "SQL tutorial"})
])

# Similarity search
results = index.query(
    vector=[0.15, 0.25, 0.35, ...],
    top_k=10
)

# Use cases:
# - Semantic search
# - Recommendation systems
# - Image similarity
# - LLM applications

-- InfluxDB, TimescaleDB, QuestDB
-- Optimized for time-series data

-- High ingestion rates
-- Automatic data retention
# Downsampling
-- Efficient time-range queries

-- Example: IoT sensor data
SELECT 
    mean(temperature),
    max(temperature)
FROM sensor_data
WHERE time >= now() - 1h
GROUP BY time(1m), sensor_id;

START: What type of data do you have?

├─ Highly relational (users ↔ orders ↔ products)
│  └─ Need ACID transactions?
│     ├─ YES → Use SQL (PostgreSQL, MySQL)
│     └─ NO → Could use NoSQL with transactions (MongoDB)
│
├─ Flexible/evolving structure
│  └─ Need complex queries?
│     ├─ YES → Use SQL with JSON support (PostgreSQL JSONB)
│     └─ NO → Use NoSQL (MongoDB)
│
├─ Key-value lookups only
│  └─ Need persistence?
│     ├─ YES → Use NoSQL (DynamoDB, Cassandra)
│     └─ NO (temporary) → Use Redis
│
├─ Graph relationships
│  └─ Use Graph DB (Neo4j, Amazon Neptune)
│
└─ Time-series data
   └─ Use Time-Series DB (InfluxDB, TimescaleDB)

Relational + ACID → SQL
Flexible + Scale → NoSQL
Both required → NewSQL or Polyglot Persistence

// Not about trends
const choice = trendy ? "MongoDB" : "PostgreSQL"; // ❌

// About requirements
const choice = needsACID && complexQueries 
  ? "PostgreSQL"
  : needsScale && flexibleSchema
    ? "MongoDB"
    : "PostgreSQL"; // ✅ (good default)