PostgreSQL Development Patterns

Overview

Enforce transaction safety, type safety, and naming conventions to prevent data corruption and runtime errors.

Core principles:

• Transactions prevent partial updates (data corruption)
• Type safety catches errors at compile time
• Naming conventions ensure consistency
• Read-write separation prevents accidental mutations

For TypeScript/Drizzle implementations: See [typescript-drizzle.md](./typescript-drizzle.md) for concrete patterns.

Transaction Management

TX_ Prefix Rule (STRICT ENFORCEMENT)

Methods that START transactions:

• Prefix method name with TX_
• Must NOT accept connection/executor parameter
• Call connection.transaction() or db.transaction() internally

Methods that PARTICIPATE in transactions:

• No TX_ prefix
• MUST accept connection/executor parameter with default value
• Execute queries using the provided executor

// GOOD: Starts transaction, has TX_ prefix, no executor parameter
async TX_createUserWithProfile(userData: UserData, profileData: ProfileData): Promise<User> {
  return this.db.transaction(async (tx) => {
    const user = await this.createUser(userData, tx);
    await this.createProfile(user.id, profileData, tx);
    return user;
  });
}

// GOOD: Participates in transaction, no TX_ prefix, takes executor
async createUser(userData: UserData, executor: Drizzle = this.db): Promise<User> {
  return executor.insert(USERS).values(userData).returning();
}

// BAD: Starts transaction but missing TX_ prefix
async createUserWithProfile(userData: UserData, profileData: ProfileData): Promise<User> {
  return this.db.transaction(async (tx) => { /* ... */ });
}

// BAD: Has TX_ prefix but takes executor parameter (allows nesting)
async TX_createUser(userData: UserData, executor: Drizzle = this.db): Promise<User> {
  return executor.transaction(async (tx) => { /* ... */ });
}

What DOES NOT count as "starting a transaction":

• Single INSERT/UPDATE/DELETE operations
• Atomic operations like onConflictDoUpdate
• SELECT queries

Type Safety

Primary Keys

Default: ULID stored as UUID

• When in doubt, use ULID: "Most things can leak in some way"
• Prevents ID enumeration attacks
• Time-sortable for indexing efficiency

Exceptions (context-dependent):

• Pure join tables (composite PK from both FKs)
• Small lookup tables (serial/identity acceptable)
• Internal-only tables with no user visibility (serial/identity acceptable)

Rule: If unsure whether data will be user-visible, use ULID.

Financial Data

Use exact decimal types (numeric/decimal) for monetary values:

• Never use float/double for money (causes rounding errors)
• Use numeric/decimal with appropriate precision and scale
• Example: numeric(19, 4) for general financial data

Why: Floating-point types accumulate rounding errors. Exact decimal types prevent financial discrepancies.

JSONB Columns

ALWAYS type JSONB columns in your ORM/schema:

• Use typed schema when structure is known
• Use Record<string, unknown> if truly schemaless
• Never leave JSONB untyped

Why: Prevents runtime errors from accessing undefined properties or wrong types.

Read-Write Separation

Maintain separate client types at compile time:

• Read-write client: Full mutation capabilities
• Read-only client: Mutation methods removed at type level
• Default to read-only for query methods
• Use read-write only when mutations needed

Why: Prevents accidental writes to replica, enforces deliberate mutation choices.

Naming Conventions

Database Identifiers

All database objects use snake_case:

• Tables: userpreferences, orderitems
• Columns: createdat, userid, is_active
• Indexes: idxtablenamecolumns (e.g., idxusersemail)
• Foreign keys: fktablenamereftable (e.g., fkordersusers)

Application code: Map to idiomatic case (camelCase in TypeScript, etc.)

Schema Patterns

Standard mixins:

• createdat, updatedat timestamps on all tables
• deleted_at for soft deletion when needed
• tenant_id for multi-tenant tables (project-dependent)

Proactive indexing:

• All foreign key columns
• Columns used in WHERE clauses
• Columns used in JOIN conditions
• Columns used in ORDER BY

Concurrency

Default isolation (Read Committed) for most operations.

Use stricter isolation when:

• Financial operations: Serializable isolation
• Inventory/count operations: Serializable isolation
• Critical sections: Pessimistic locking (SELECT ... FOR UPDATE)

Migrations

Always use generate + migrate workflow:

1. Change schema in code
2. Generate migration file
3. Review migration SQL
4. Apply migration to database

Never use auto-push workflow in production.

Common Mistakes

Red Flags - STOP and Refactor

Transaction management:

• Method calls .transaction() but no TX_ prefix
• Method has TX_ prefix but accepts executor parameter
• Multi-step operation without transaction wrapper

Type safety:

• JSONB column without type annotation
• UUID/ULID stored as plain string type
• No separation between read and write clients
• Float/double types for monetary values

Schema:

• Missing indexes on foreign keys
• No createdat/updatedat timestamps
• camelCase or PascalCase in database identifiers

All of these mean: Stop and fix immediately.

Reference

For TypeScript/Drizzle concrete implementations: [typescript-drizzle.md](./typescript-drizzle.md)