diff --git a/src/lib/db/index.ts b/src/lib/db/index.ts
index 21e2efaa..3322dd9f 100644
--- a/src/lib/db/index.ts
+++ b/src/lib/db/index.ts
@@ -22,7 +22,12 @@ const connectionString = process.env.DATABASE_URL!;
 // multi-widget dashboards, React Query refetch-on-focus) and a single
 // admin clicking around can saturate 20 slots. Production stays at the
 // conservative 20 so we don't hammer postgres in a multi-replica deploy.
-const POOL_MAX = process.env.NODE_ENV === 'development' ? 60 : 20;
+//
+// 60 was too aggressive locally — postgres + the drizzle logger creates
+// massive log volume that backed up node's stderr, blocking the event
+// loop on otherwise-cheap requests. 30 is a middle ground that holds
+// during clients-page fanout without log-storm.
+const POOL_MAX = process.env.NODE_ENV === 'development' ? 30 : 20;
 
 const queryClient = postgres(connectionString, {
   max: POOL_MAX,
@@ -37,9 +42,15 @@ const queryClient = postgres(connectionString, {
   },
 });
 
+// Drizzle query logging is opt-in via DRIZZLE_LOG=1 in development.
+// Was on-by-default in dev but the volume (per-query SQL + parameters
+// for 60+ queries per page load) saturated process.stderr and blocked
+// the Node event loop, causing apparent dev-server "hangs" after
+// repeated navigation. The HTTP request logs from Next still show
+// query routing, which is enough for normal debugging.
 export const db = drizzle(queryClient, {
   schema,
-  logger: process.env.NODE_ENV === 'development',
+  logger: process.env.DRIZZLE_LOG === '1',
 });
 
 /** Close the underlying connection pool. Used by the vitest teardown so