Database on

Lesson 9: Testing with Real Databases — Mocking sql.DB is lying to yourself

Wed, 18 Feb 2026 00:00:00 +0000

For years, the standard advice for testing Go database code was to use sqlmock — a library that intercepts database calls and lets you assert which queries were run. I used it for a while. Then I started finding production bugs that my sqlmock tests were actively hiding: constraint violations that only happen with real Postgres, query plan differences, JSON operator behavior, NULL handling edge cases, transaction isolation behavior. sqlmock tests were passing while the same code was failing in production. That’s worse than no tests at all.

Lesson 8: Migrations Without Downtime — ALTER TABLE can lock your entire database

Tue, 27 Jan 2026 00:00:00 +0000

The first time I caused a production outage with a database migration, I was adding a NOT NULL column to a table. The migration looked innocent. It ran fine on staging with 1,000 rows. In production with 40 million rows, it locked the entire table for 11 minutes while Postgres rewrote every row. Every write to that table failed with a lock timeout. We rolled back the app but couldn’t roll back the migration. It was a terrible morning.

Lesson 7: The N+1 Problem — One query per row is a performance bug

Thu, 25 Dec 2025 00:00:00 +0000

The N+1 problem is the most common database performance issue I find when reviewing Go code, and it’s especially sneaky because it looks totally fine in development. You have a list of 10 users, you fetch their orders, 11 queries, no problem. You deploy to production, the table has 50,000 users, your endpoint suddenly takes 40 seconds, and you get a 3am page. The queries were always there — you just didn’t notice them until the data grew.

Lesson 6: Context with Database Queries — Every query needs a timeout

Wed, 03 Dec 2025 00:00:00 +0000

We once had a query that ran for 47 minutes. I’m not joking. A reporting query that worked fine on the test dataset decided to do a full sequential scan on a 200M-row table in production because someone dropped an index by accident the night before. The query just ran. And ran. And ran. The connection was held the whole time, blocking the pool. New requests started queuing. Within 10 minutes, the service was effectively down — not because of an error, but because every database connection was held by queries waiting for that one slow one to finish.

Lesson 5: sqlc vs ORM vs Raw SQL — Pick your tradeoff, not your religion

Wed, 29 Oct 2025 00:00:00 +0000

Every time someone asks “should I use GORM or raw SQL?” a flame war breaks out. I’ve been on both sides of that argument, and I’ve shipped production systems using all four approaches — raw SQL, GORM, sqlc, and Ent. My opinion now is boring: each one is the right choice in a specific context, and none of them is universally correct. The question isn’t which one is best, it’s which tradeoffs you’re signing up for.

Lesson 4: The Repository Pattern — Sometimes a function is enough

Thu, 02 Oct 2025 00:00:00 +0000

The repository pattern is one of those ideas that sounds great in an architecture talk and causes real pain when applied indiscriminately to a Go codebase. I’ve seen teams add a UserRepository interface with five methods, a concrete postgresUserRepository implementation, and a mockUserRepository for tests — and then wonder why everything takes three times as long to write. I’ve also seen teams skip the pattern entirely and end up with *sql.DB threaded through 40 different functions, impossible to test without a real database.

Lesson 3: Transactions That Don't Bite — Begin, defer rollback, commit

Sun, 07 Sep 2025 00:00:00 +0000

Transactions are the part of database programming where “it’s fine most of the time” really isn’t good enough. A buggy SELECT just returns wrong data. A buggy transaction can leave your database in a half-written state — an order placed without inventory decremented, money debited without the transfer completing, a user created without their profile record. The bugs are subtle, often don’t manifest in testing, and only show up in production when two things happen at the same time.

Lesson 2: Connection Pool Tuning — Your pool config is probably wrong

Fri, 08 Aug 2025 00:00:00 +0000

Here’s a scenario that played out for me once: service is running fine for weeks, then we double traffic, and suddenly requests start timing out. Not all of them — maybe 10%. The logs show pq: sorry, too many clients already. Postgres is refusing connections. But we have a connection pool — that’s the whole point, right? Why is Postgres seeing more connections than it can handle?

Because database/sql’s default pool settings are almost certainly wrong for production, and most people never change them.

Lesson 1: database/sql Done Right — The stdlib is better than you think

Tue, 08 Jul 2025 00:00:00 +0000

I spent a long time reaching for third-party database libraries in Go before I actually read the database/sql docs. When I finally did, I was embarrassed — the stdlib had everything I needed and I’d been adding dependencies for no reason. The problem isn’t that database/sql is limited. The problem is that it has a handful of non-obvious behaviors that, if you don’t know about them, will burn you in production. Once you internalize those, you’ll write better database code than most people using ORMs.

Lesson 10: Redis, MongoDB, and Non-Relational Stores — Beyond SQL

Sun, 10 Nov 2024 15:37:00 +0000

I spent a week optimizing a Postgres query that powered a leaderboard. It involved a complex window function over millions of rows, and no amount of indexing got it under 200ms. Then a senior engineer walked over, looked at the query, and said “Why isn’t this in Redis?” He was right. I replaced 30 lines of SQL with a sorted set and the response time dropped to 2ms.

Not every data problem is a SQL problem. Sometimes you need the right tool, not a better query plan.

Lesson 9: N+1 Queries, Indexes, and EXPLAIN — Database performance in Rust

Wed, 06 Nov 2024 07:52:00 +0000

A coworker asked me to look at an endpoint that was taking 8 seconds to return 50 orders. The table had 200K rows — not big by any standard. I opened the code, and the pattern was immediately obvious: fetch 50 orders, then for each order, fetch its items in a separate query. Fifty-one database round trips where one would do.

The N+1 query problem is the most common performance mistake in database-backed applications, and Rust doesn’t magically prevent it. You need to know what to look for.

Lesson 8: Testing with Real Databases — No more mocking SQL

Sun, 03 Nov 2024 13:15:00 +0000

I spent two days debugging a production issue where a query returned duplicate rows. The unit tests all passed — every mock returned exactly the expected data. The problem was a missing DISTINCT in a JOIN query that only manifested with real data containing multiple matching rows. The mocks were too perfect. They never produced the messy data that real databases contain.

That was when I stopped mocking SQL.

The Problem with Mocking Database Calls

Mocking databases is popular because it’s convenient. You don’t need Docker, you don’t need a test database, your tests run in milliseconds. But you’re testing the wrong thing.

Lesson 7: Building Type-Safe Query Builders — Queries that can't be wrong

Fri, 01 Nov 2024 09:28:00 +0000

I was reviewing a PR that had a search endpoint with 12 optional filters. The handler was a 200-line function full of if let Some(...) blocks, each appending a different SQL fragment to a String. It worked — until someone forgot a space between AND and a column name, and the query silently returned zero results instead of erroring. No compile error. No test failure. Just a missing space in a string.

Lesson 6: The Repository Pattern in Rust — Abstracting persistence

Wed, 30 Oct 2024 16:40:00 +0000

I once inherited a codebase where every HTTP handler had raw SQL queries inline — sqlx::query! calls scattered through 80+ route handlers. Changing a table name meant grep-and-replace across the entire project. Adding a cache layer meant touching every handler. Testing a handler meant spinning up a real database. It worked, technically, but nobody wanted to touch it.

The repository pattern fixes this. It puts a wall between your business logic and your database, and that wall pays for itself fast.

Lesson 5: Transactions and Error Rollback — Atomic operations

Mon, 28 Oct 2024 10:05:00 +0000

A payment service I worked on had a subtle bug: it deducted money from the user’s wallet, then tried to create an order record. If the order insert failed — constraint violation, timeout, anything — the money was already gone. The user’s balance was decremented but they had no order. We called these “ghost charges” internally, and customers called them something less polite.

The fix was embarrassingly simple: wrap both operations in a transaction.

Lesson 4: Schema Migrations in Rust Projects — Evolving your database

Sat, 26 Oct 2024 19:12:00 +0000

A teammate once ran ALTER TABLE orders DROP COLUMN status on the production database because he’d tested it locally and “it worked fine.” What he didn’t realize was that three other services depended on that column, and they all started throwing errors simultaneously. We spent the evening restoring from a backup.

Schema migrations exist to prevent exactly this — they’re version control for your database.

The Problem

Your database schema isn’t static. Features get added, requirements change, data models evolve. You need a way to:

Lesson 3: Connection Pooling with deadpool and bb8 — Managing database connections

Thu, 24 Oct 2024 14:35:00 +0000

I once watched a Rust service fall over under modest load — maybe 200 concurrent requests — because every request opened a new Postgres connection, used it for one query, and dropped it. The database was spending more time on TLS handshakes and connection setup than on actual queries. CPU was fine, memory was fine, but pg_stat_activity showed 200+ connections churning constantly. The fix took ten lines of code: add a connection pool.

Lesson 2: Diesel — The ORM approach

Tue, 22 Oct 2024 08:47:00 +0000

I was two weeks into a project where I had to write about 40 CRUD endpoints for an admin panel. Each one needed the same pattern: validate input, build a query, map results to a struct, handle errors. By endpoint number six, I was copy-pasting SQLx queries and changing column names. That’s when a colleague asked, “Why aren’t you using Diesel?”

He was right. Sometimes you don’t want to write SQL. Sometimes you want the boilerplate to disappear.

Lesson 1: SQLx — Compile-time checked queries

Sun, 20 Oct 2024 11:23:00 +0000

I shipped a typo in a SQL column name to production last year. The column was user_nme instead of user_name. The Go service compiled fine, the tests passed (they used mocks), and the bug sat in production for three hours before a customer reported it. Three hours of silent failures because the query returned zero rows instead of erroring out.

That was the day I started using SQLx in Rust. I haven’t shipped a SQL typo since.