Go Database Patterns on Atharva Pandey

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.