Bun Database Integration

Your typical Node.js database setup requires 4+ packages just for PostgreSQL: pg, @types/pg, pg-pool, and pg-format. When Node.js 20 dropped, half my projects broke because node-gyp couldn't rebuild the native modules. Spent 3 hours fixing compilation errors.

Bun v1.2.21 ships with database drivers built-in. Database connections are noticeably faster - my API responses went from ~300ms to ~120ms on my usual test setup. Not scientific, but real enough.

Single API for Multiple Databases

Instead of learning separate APIs for pg, mysql2, and better-sqlite3, Bun uses one consistent interface:

import { sql } from 'bun';

// PostgreSQL - same syntax as before, just faster
const postgres = sql`postgres://user:pass@localhost/db`;

// MySQL - works with your existing Docker setup
const mysql = sql`mysql://user:pass@localhost/db`;

// SQLite - perfect for local dev and testing  
const sqlite = sql`sqlite:///path/to/database.db`;

// Same query for all three (finally!)
const users = await postgres`SELECT * FROM users WHERE active = ${true}`;

Connections feel snappier. Complex queries with joins don't show much improvement, but simple CRUD operations are noticeably faster. Your mileage will vary depending on network latency and query complexity.

SQLite: No More Compilation Hell

SQLite with Node.js is a fucking nightmare. better-sqlite3 breaks every time Node updates. On M1 Macs, rebuilding takes 5+ minutes if it works at all. Docker builds fail with:

gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2

I've wasted entire afternoons debugging these compilation issues. Alpine Linux containers are especially painful.

Bun's built-in SQLite requires no compilation or native dependencies:

import { Database } from 'bun:sqlite';

const db = new Database('app.db'); // Creates file if missing

// Prepared statements automatically (no manual optimization)
const getUser = db.query('SELECT * FROM users WHERE id = ?');
const user = getUser.get(123);

// Synchronous transactions that don't suck
db.transaction(() => {
  db.run('INSERT INTO logs (message) VALUES (?)', 'User logged in');
  db.run('UPDATE users SET last_seen = ? WHERE id = ?', Date.now(), 123);
})(); // Either all succeed or all fail

SQLite is fast enough for most apps unless you need heavy concurrent writes. For local dev and testing, it's perfect - no Docker PostgreSQL setup bullshit.

ORM Reality Check

Prisma still needs Node.js for prisma generate, which defeats the point of switching to Bun. Works fine but you're running two runtimes. The setup guide explains the pain.

Drizzle is what you actually want. Works directly with Bun.SQL, generates readable SQL, and doesn't make you hate ORMs. The benchmarks show it's barely slower than raw SQL.

import { drizzle } from 'drizzle-orm/bun-sql';
import { sql } from 'bun';

const db = drizzle(sql`postgres://localhost/mydb`);
const users = await db.select().from(usersTable).where(eq(usersTable.active, true));
// Generates proper SQL, doesn't do weird magic

TypeORM is slow everywhere. Decorators and reflection make everything sluggish. Avoid unless you're masochistic.

Migrations Don't Totally Suck

Drizzle Kit generates migrations that make sense instead of cryptic bullshit. File I/O is fast enough that reading raw .sql files works fine for simple setups.

When shit breaks, you're debugging one thing (Bun) instead of figuring out which of your 6 database packages is incompatible with the others.

Additional Resources

• SQLite optimization techniques for high-performance applications
• PostgreSQL connection best practices in production environments
• MySQL 8.0 performance tuning guide from Oracle
• Database design patterns by Martin Fowler
• ACID transaction principles explained
• Database indexing strategies comprehensive guide
• Connection pooling theory and practice
• SQL query optimization fundamentals

Database connections will fail at 3am when you're oncall. Here's what breaks and how to fix it without losing your mind.

Connection Pooling

Pooling happens automatically, but you'll hit connection limits under load. PostgreSQL defaults to 100 connections, and you'll get this lovely error:

Error: sorry, too many clients already

This killed our Black Friday traffic last year. Set explicit limits before you find out the hard way:

import { sql } from 'bun';

// Basic setup - pooling handled automatically
const db = sql`postgres://user:pass@localhost/db`;

// Production setup - specify limits before you hit them
const db = sql`postgres://user:pass@localhost/db?max_connections=20&idle_timeout=30`;

// Health check for load balancers
async function healthCheck() {
  try {
    await db`SELECT 1`; // Fails fast on connection issues
    return { database: 'healthy' };
  } catch (error) {
    console.error('Database connection failed:', error.message);
    return { database: 'down', error: error.message };
  }
}

Bun uses less memory per connection than Node.js, so you can run more concurrent connections. We handle 50+ connections per process without issues, but this varies by app.

Error Handling: Shit Breaks

Networks drop. Servers restart. Your retry logic needs to handle this or you're fucked:

async function queryWithRetry(query, values, maxRetries = 3) {
  for (let attempt = 1; attempt <= maxRetries; attempt++) {
    try {
      return await db(query, ...values);
    } catch (error) {
      console.warn(`Attempt ${attempt} failed: ${error.message}`);
      
      // Don't retry stupid mistakes
      if (error.code === '42P01' || error.code === '23505') {
        throw error; // Table doesn't exist, constraint violation = your fault
      }
      
      // Handle specific PostgreSQL error codes correctly
      // Reference: https://www.enterprisedb.com/blog/application-high-availability-and-resiliency-steps-improve-transaction-retry
      
      // Exponential backoff because hammering won't help
      if (attempt < maxRetries) {
        const delay = Math.min(1000 * Math.pow(2, attempt - 1), 5000);
        await Bun.sleep(delay);
      } else {
        throw new Error(`Gave up after ${maxRetries} attempts: ${error.message}`);
      }
    }
  }
}

Transactions: Don't Lose People's Money

Transactions are faster in Bun, but they'll still fuck you if you don't handle concurrency properly. This cost us 2 hours when a race condition let someone withdraw money twice:

// Don't lose people's money
async function transferMoney(fromAccount, toAccount, amount) {
  return await db.transaction(async (tx) => {
    // FOR UPDATE locks the row - critical for money stuff
    const balance = await tx`
      SELECT balance FROM accounts WHERE id = ${fromAccount} FOR UPDATE
    `;
    
    if (balance[0]?.balance < amount) {
      throw new Error('Insufficient funds'); // Auto-rollback
    }
    
    await tx`UPDATE accounts SET balance = balance - ${amount} WHERE id = ${fromAccount}`;
    await tx`UPDATE accounts SET balance = balance + ${amount} WHERE id = ${toAccount}`;
    
    return { success: true, transferAmount: amount };
  });
}

// For SQLite - handle write concurrency or it will bite you
async function atomicUpdate(userId, data) {
  return db.transaction(() => {
    // SQLite transactions are sync - faster but different from PostgreSQL
    const user = db.query('SELECT * FROM users WHERE id = ?').get(userId);
    if (!user) throw new Error('User not found');
    
    return db.query('UPDATE users SET data = ?, updated_at = ? WHERE id = ?')
      .run(JSON.stringify(data), Date.now(), userId);
  })(); // Don't forget the () at the end
}

Monitoring: Don't Overthink It

Start with basic query timing. Log slow shit. Fix it. Don't build a fucking NASA monitoring system on day one:

// Simple query timing that actually works
async function timedQuery(query, ...values) {
  const start = performance.now();
  
  try {
    const result = await db(query, ...values);
    const duration = performance.now() - start;
    
    // Log slow queries - adjust threshold based on your app
    // Database-level monitoring: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_DatabaseInsights.SlowSQL.html
    if (duration > 1000) {
      console.warn(`Slow query (${duration.toFixed(0)}ms): ${query.toString().slice(0, 50)}...`);
    }
    
    return result;
  } catch (error) {
    const duration = performance.now() - start;
    console.error(`Query failed (${duration.toFixed(0)}ms): ${error.message}`);
    throw error;
  }
}

Loading a Million Rows Will Kill Your Server

Don't do it. Your server will run out of memory and die. Page that shit:

// Process large datasets without dying
async function processBigTable(callback, batchSize = 1000) {
  let offset = 0;
  let hasMore = true;
  
  while (hasMore) {
    const batch = await db`
      SELECT * FROM huge_table 
      ORDER BY id 
      LIMIT ${batchSize} OFFSET ${offset}
    `;
    
    if (batch.length === 0) {
      hasMore = false;
    } else {
      for (const row of batch) {
        await callback(row);
      }
      offset += batchSize;
      
      // Give garbage collector a chance to breathe
      if (offset % 10000 === 0) {
        await new Promise(resolve => setImmediate(resolve));
      }
    }
  }
}

Migrations: Don't Break Production

Test your migrations. Use transactions. Have a rollback plan or you'll have a bad time:

// Simple migration runner that won't fuck up your data
async function runMigrations() {
  // Prevent multiple deployments from running migrations simultaneously
  const lockAcquired = await db`
    INSERT INTO migration_lock (locked_at) VALUES (NOW())
    ON CONFLICT DO NOTHING
    RETURNING locked_at
  `;
  
  if (lockAcquired.length === 0) {
    console.warn('Another migration is running, skipping...');
    return;
  }
  
  try {
    const pending = await getPendingMigrations();
    console.log(`Running ${pending.length} migrations...`);
    
    for (const migration of pending) {
      console.log(`Running: ${migration.name}`);
      
      await db.transaction(async (tx) => {
        await tx.unsafe(migration.sql); // DDL operations
        await tx`INSERT INTO migrations (name) VALUES (${migration.name})`;
      });
    }
  } finally {
    await db`DELETE FROM migration_lock`;
  }
}

Connection overhead was killing our API response times. Switching to Bun made pages load noticeably faster. Users stopped bitching about performance, which was nice.

Additional Production Resources

• PostgreSQL performance monitoring guide from official documentation
• Database connection pooling patterns for high-traffic applications
• Transaction isolation levels explained with practical examples
• SQL query performance optimization tools and techniques
• Database backup strategies for production systems
• Connection limit troubleshooting in PostgreSQL
• Database migration best practices by Martin Fowler