Nestjs Database

2. Access Pattern Analysis (The "How")

• Transactional (OLTP): "User buys items to cart".
  • Requirement: Strong Consistency (ACID). SQL is mandatory.
• Analytical (OLAP): "Dashboard showing sales trends".
  • Requirement: Aggregation speed. Columnar storage (ClickHouse) or Read Replicas.
• High Throughput Write: "1M events/sec".
  • Requirement: Append-only speed. Cassandra / DynamoDB (Leaderless replication).

3. Decision Matrix

Patterns

• Repository Pattern: Isolate database logic.
  • TypeORM: Inject @InjectRepository(Entity).
  • Prisma: Create a comprehensive PrismaService.
• Abstraction: Services should call Repositories, not raw SQL queries.

Configuration (TypeORM)

• Async Loading: Always use TypeOrmModule.forRootAsync to load secrets from ConfigService.
• Sync: Set synchronize: false in production; use migrations instead.

Scaling & Production

• Read Replicas: Configure separate replication connections (Master for Write, Slaves for Read) in TypeORM/Prisma to distribute load.
• Connection Multiplexing:
  • Problem: Scaling K8s pods to 100+ exhausts DB connection limits (100 pods * 10 connections = 1000 conns).
  • Solution: Use PgBouncer (Postgres) or ProxySQL (MySQL) in transaction mode. Do NOT rely solely on ORM pooling.
• Migrations:
  • NEVER run synchronize: true in production.
  • Execution: Run migrations via a dedicated "init container" or CD job step. Do NOT auto-run inside the main app process on startup (race conditions when scaling to multiple pods).
• Soft Deletes: Use @DeleteDateColumn (TypeORM) or middleware (Prisma) to preserve data integrity.

Architectures (Multi-Tenancy & Sharding)

• Column-Based (SaaS Standard): Single DB, tenant_id column.
  • Scale: High. Isolation: Low.
  • Code: Requires Row-Level Security (RLS) policies or strict Where scopes.
• Schema-Based: One DB, one Schema per Tenant.
  • Scale: Medium. Isolation: Medium. Good for B2B.
• Database-Based: One DB per Tenant.
  • Scale: Low (max ~500 tenants per cluster). Isolation: High.
  • Code: Requires "Connection Switching" middleware. Complex.
• Horizontal Sharding:
  • Logic: Shard massive tables by a key (e.g. user_id) across physical nodes to exceed single-node write limits.
  • Complexity: Extreme. Avoid until >10TB data. Use "Partitioning" first.
• Partioning (Postgres):
  • Strategy: Use native Table Partitioning (e.g., by range/date) for massive tables (Logs, Audit, Events).
  • App Logic: Ensure partition keys (e.g., created_at) are included in WHERE clauses to enable "Partition Pruning".

Migrations & Data Evolution

• Separation:
  • Schema Migrations (DDL): Structural changes (CREATE TABLE, ADD COLUMN). Fast. Run before app deploy.
  • Data Migrations (DML): transforming data (UPDATE users SET name = ...). Slow. Run as background jobs or separate scripts purely to avoid locking tables for too long.
• Zero-Downtime Field Migration (Expand-Contract Pattern):
  1. Expand: Add new column new_field (nullable). Deploy App v1 (Writes to both old and new).
  2. Migrate: Backfill data from old to new in batches (background script).
  3. Contract: Deploy App v2 (Reads/Writes only new). Drop old_field in next schema migration.
• Seeding:
  • Dev: Use factories (@faker-js/faker) to generate mock data.
  • Prod: Only seed static dictionaries (Roles, Countries) using "Upsert" logic to prevent duplicates.

Best Practices

1. Pagination: Mandatory. Use limit/offset or cursor-based pagination.
2. Indexing: Define indexes in code (decorators/schema) for frequently filtered columns (where, order by).
3. Transactions: Use QueryRunner (TypeORM) or $transaction (Prisma) for all multi-step mutations to ensure atomicity.