A hands-on benchmark built with a Node harness and a byte-counting TCP proxy measures the real wire cost of WebSocket, SSE, and long polling delivering 1,000 events. WebSocket used 119,692 bytes, SSE 131,596 (10% more), and HTTP/1.1 long polling 884,698 bytes (7.4x), mostly re-sent headers. On HTTP/2, long polling drops to 182,475 bytes (1.56x payload). Latency differences at low event rates were under 0.3ms across all three; long polling only degrades when events arrive faster than a round trip. Server memory for 500 idle connections favored WebSocket (6.2-6.7MB) over SSE (11MB) and long polling (10.3-10.9MB). Practical failure modes covered include idle timeouts, proxy buffering, and the six-connections-per-origin HTTP/1.1 cap on SSE. The recommendation: build SSE first for server-to-client feeds, move to WebSocket only when upstream or binary data is needed.

Almost every notable managed Postgres provider bundles a connection pooler like PgBouncer, according to a survey of major providers including AWS RDS, Azure, Google Cloud SQL, Supabase, Neon, DigitalOcean, and others. Only IBM Cloud and Oracle OCI lack a managed pooling option, and both are dismissed as unlikely choices outside enterprise sales cycles. The piece argues connection pooling is effectively a mandatory add-on because Postgres itself handles many connections poorly, and contrasts this with MySQL and MongoDB, which don't require a bolted-on pooler. The wasted effort of every provider building homegrown pooling setups and every user having to learn PgBouncer's quirks (like the lack of LISTEN/NOTIFY support) is framed as evidence that native connection pooling in Postgres itself would be a high-impact improvement.

An engineering leader shares why AI-based code review tools like Cursor's BugBot and custom Claude code review skills became too slow, noisy, and expensive (hitting $1000/day in one case) for a team producing thousands of PRs a quarter. The fix that worked: converting team-specific coding rules from markdown guidelines into custom linters, which run in seconds, are deterministic, can run in-editor and on pre-commit hooks, and stop agents from ever pushing bad code. Several example custom lint rules are shared, covering design system consistency, logging, testing conventions, and prose quality.

A case study describes how MongoDB adopted GitDailies, a GitHub PR alerting and metrics tool, to help engineering teams meet PR review SLAs. Customizable alerts, Slack integration, and personalized dashboards replaced ineffective existing alerting, reportedly cutting review times by up to 54% for one team and over 28% for nearly half the teams involved.

VoidZero, the company behind Vite founder Evan You, has launched the beta of Vite+, a unified web toolchain accessible through a single vp command. It bundles Vite, Vitest, Rolldown, tsdown, Oxlint and Oxfmt with a built-in task runner, offering commands like vp dev, vp check, vp test, vp build, vp pack and vp run. Since its alpha, the team has merged over 500 pull requests, expanded vp migrate coverage, and added enterprise features like organisation templates. Over 1,300 public repositories already use it, including Dify, BlockNote and Cloudflare's vinext. Reception on Hacker News was largely positive, though a widely shared GitHub write-up by Jared Wilcurt criticized its vp env Node version manager and warned about ecosystem lock-in and heavy reliance on Rust rewrites of existing tools.

G# is a new open-source, Go-inspired programming language that compiles to .NET, targeting systems programming and mobile applications while interoperating with existing .NET libraries and NuGet packages. It supports .NET 8 through 10 (10 preferred), offers a VS Code extension with language server support, and blends .NET-style async/await with Go-like fire-and-forget concurrency and channels via an optional extensions package. The language uses packages, funcs, structs and classes, and features like if let and for in for concise null checks and iteration. Beyond general development, it's positioned as an educational language and a lightweight candidate for WebAssembly and Hyperlight microVM scenarios, useful for developers moving from Swift or Kotlin into the .NET ecosystem.

A deep retrospective revisits years of Crunchy Data's Postgres advice on COPY, TOAST, BRIN indexes, covering indexes, and partitioning, mapping which Postgres versions (14 through the upcoming 19) changed the underlying mechanics while the core recommendations largely held. Highlights for Postgres 19 (currently in beta) include SIMD-accelerated COPY parsing, ON_ERROR SET_NULL, LZ4 becoming the default TOAST compression algorithm, native REPACK CONCURRENTLY, native MERGE/SPLIT PARTITION syntax, COPY TO working directly on partitioned parents, autoscaling async I/O workers, parallel autovacuum workers, and JIT being turned off by default after being on since version 12. The piece closes with a checklist of advice that remains unchanged across all these releases.

A benchmark sweep of a PostgreSQL instance from 1 to 400 connections shows throughput peaking at 48 connections (18,039 tps) and dropping 37% by 400 connections, while average latency multiplied 13x. The piece explains why connections are OS processes competing for cores rather than free capacity, tests the Universal Scalability Law fit (R²=0.94, predicted optimum 45.1), evaluates the (cores×2)+spindles formula (predicts 9, far off the measured 48), and finds that synchronous_commit=off raises throughput but does not shift the peak. It closes with practical guidance: watch queue depth (cl_waiting in PgBouncer, pending-threads in HikariCP) rather than connection count, account for instances × pool size multiplication, and use transaction pooling or RDS Proxy for Lambda to avoid connection exhaustion.