Database Plumbing Still Generates Strong Opinions
Two separate database threads drew substantive engagement today. The PgBouncer scaling post showed a team getting 4x throughput by running multiple PgBouncer processes with SO_REUSEPORT, a kernel-level trick that lets multiple sockets share a port. The SQLite strict tables post was simpler: a reminder that SQLite defaults to loose typing, and you have to opt into strict mode explicitly, which most people don't know.
The pattern: Postgres infrastructure optimization is still a live, active area of builder interest. The PgBouncer thread got into Kubernetes deployments, peer configurations, and the tradeoffs of horizontal vs. vertical scaling for connection poolers. This isn't glamorous, but it's the kind of thing that bites teams at scale.
The SQLite thread had a telling comment: 'I would've thought this was the default.' That captures a lot of SQLite footguns. The database is so easy to start with that people often don't read the manual closely enough to know what they're not getting.
So what?
If you're running Postgres at any meaningful scale and haven't audited your PgBouncer setup, the SO_REUSEPORT trick is worth 30 minutes of your time. For SQLite users building anything that stores user data, strict mode should be in your setup checklist, it's a one-line change that prevents a class of silent data corruption bugs.