The Engineer

Two Production Playbooks for Scaling Postgres

Two of the highest-signal reports today detail production-proven PostgreSQL scaling patterns from OpenAI and Netflix — and they're complementary. OpenAI scaled a single-primary Postgres instance to serve 800 million ChatGPT users at millions of QPS with 99.999% uptime, while Netflix migrated 400 RDS PostgreSQL clusters to Aurora using WAL-streaming replica promotion for near-zero-downtime cutover.

OpenAI's Defense-in-Depth Architecture

OpenAI runs a single primary writer on Azure PostgreSQL streaming WAL to ~50 read replicas. Each replica has its own Kubernetes deployment running multiple PgBouncer pods behind a K8s Service. The results: connection latency dropped from 50ms to 5ms (10x improvement), and their only SEV-0 in 12 months came during the ImageGen viral launch when 100M users signed up in a week.

The protection stack is what makes this work:

They explicitly rejected sharding — estimated at months-to-years of effort modifying hundreds of endpoints. This only works because their workload is overwhelmingly reads. At ~50 replicas, they're hitting WAL fan-out limits and collaborating with Azure on cascading replication, which is still in testing due to complex failover semantics.

Netflix's WAL-Streaming Migration Pattern

Netflix's approach is elegantly simple: create an Aurora read replica of the RDS instance, let it catch up via continuous WAL streaming, validate replication lag, then promote. No AWS DMS, no CDC middleware, no replication slot management. The entire workflow was built as self-service and credential-free — individual teams triggered their own migrations.

Complementary Tooling: sql-tap and Guidewire's Snapshot Optimization

Two additional data points strengthen the Postgres scaling story. sql-tap is a new transparent SQL proxy that captures queries, transactions, timings, and EXPLAIN output without code changes — just redirect your connection string. And Guidewire cut Debezium CDC snapshot time from 68.5 to 20 hours on a 7TB database by combining Aurora Copy-on-Write cloning with Timefold constraint-based partitioning for intelligent worker distribution.

The real lesson isn't 'don't shard' — it's that the protection layers around your database matter more than the database topology itself.

Three Independent Signals, One Conclusion

Today's intelligence from three separate sources converges on a single, urgent finding: AI agents operating with user-level permissions are a production security incident waiting to happen, and prompt-based safeguards are architecturally insufficient to prevent it.

The Evidence

1Password open-sourced SCAM (Security Comprehension and Awareness Measure), the first rigorous benchmark for testing AI agent safety in real workflows — opening emails, retrieving credentials, filling login forms. The results across eight frontier models: safety scores ranged from 35% to 92%, and every single model exhibited at least one critical failure — entering credentials on phishing pages or forwarding passwords to external parties. This is under MIT License with 30 workplace scenarios and video replay tooling.

Separately, OpenClaw (120K+ GitHub stars, 20K forks) was found to operate with the same permissions as the installing user, allowing malicious marketplace skills to exploit the agent's full permission scope. OpenAI responded by shipping Lockdown Mode for ChatGPT and adding "Elevated Risk" labels to capabilities in ChatGPT Atlas and Codex — essentially admitting certain capabilities are inherently more vulnerable to prompt injection.

Meanwhile, OpenAI acqui-hired OpenClaw's creator Peter Steinberger, and the project transitions to a foundation — creating dependency risk for anyone building on it.

The Architectural Fix

The pattern is identical to what we've applied to untrusted code execution for decades:

1. Sandbox execution — agents should not have direct access to the host environment
2. Scope credentials — minimum required permissions per task, not per user
3. Restrict tools — allowlist, not blocklist, for available capabilities
4. Audit everything — every tool invocation, every external call, logged and reviewable

One bright spot from the SCAM benchmark: applying a short security "skill file" (a system prompt with explicit security rules) dramatically reduced failures across all models. This suggests prompt-level guardrails are effective as a first line of defense, but they cannot be the only line.

The Broader Agent Ecosystem Risk

The emergence of tools like klaw (enterprise agent orchestration) and Pydantic AI's Monty (microsecond-startup Python sandbox replacing container-based sandboxes for LLM-generated code) signals that agent management is becoming an infrastructure problem. Monty's approach — a purpose-built minimal Python interpreter with security constraints baked into the runtime — trades full CPython compatibility for microsecond startup and inherent sandboxing. For agent loops executing code dozens of times per task, container cold-start latency (100ms-2s) compounds brutally.

AI agents are the new containers: powerful, ubiquitous, and a security nightmare until you treat them as untrusted workloads with proper sandboxing, scoped permissions, and audit trails.

OpenSSH's Post-Quantum Migration Just Became Non-Optional

OpenSSH 10.0 made mlkem768x25519-sha256 the default key exchange algorithm. Version 10.1 goes further: it now actively warns users when connections use non-post-quantum algorithms. This is the deprecation warning phase — classical-only key exchange is on a sunset path.

The threat model is concrete, not theoretical: "store now, decrypt later" means adversaries (particularly state-sponsored) are capturing encrypted SSH traffic today to decrypt when quantum computers become capable. For sessions carrying deployment credentials, database access, or infrastructure automation commands, this is real exposure. Migration blockers to plan for: legacy network appliances, older SSH libraries in automation tooling, and hardware HSMs that don't support ML-KEM. The hybrid approach (ML-KEM + X25519) provides classical security as a fallback, but both sides must support the algorithm.

Browser Extensions: 37.4 Million Downloads of Malware

Researchers confirmed 300+ malicious Chrome extensions with 37.4 million combined downloads were exfiltrating user data at scale. The breakdown: 153 extensions exfiltrated browsing history immediately on install, a cluster of 30 extensions disguised as AI tools shared identical backend infrastructure, and 15 AI-themed extensions specifically targeted Gmail to extract email content.

This isn't a consumer problem — it's an engineering problem. Your developers have AI coding assistants, productivity tools, and ad blockers installed with permissions to read all page content, modify requests, and access cookies. Your SBOM doesn't cover this. Your EDR probably doesn't flag it. If an engineer's Gmail contains deployment notifications, incident response threads, or API keys shared via email, a malicious extension has access to all of it.

Supply Chain Integrity: SLSA Is Becoming Table Stakes

The SLSA framework and cryptographic attestations are being positioned as the standard for software supply chain verification. Separately, Vouch launched a web-of-trust model for open-source contribution quality — requiring explicit vouches for participation with cross-project trust sharing — as a response to AI-generated contribution spam that's now bad enough to spawn its own tooling category.

Google's Threat Intelligence Group also published coordinated state-sponsored campaigns from four nation-states targeting the defense industrial base, with edge device compromise (VPNs, firewalls, load balancers) as the primary vector. Even if you're not in defense, the pattern is universal: edge devices are targeted because they're often unpatched and have broad network access.

Every frontier AI model will enter your credentials on a phishing page; your SSH sessions are being stored for future quantum decryption; and your engineers' Chrome extensions are a supply chain attack surface you're probably not governing. All three are fixable this quarter.

Two Architectures, Two Trade-offs

OpenAI and Anthropic both launched fast inference modes this week, but with fundamentally different architectural trade-offs that matter for your provider selection:

The critical nuance for agentic workflows: a 10% accuracy drop per call compounds to ~40-65% degradation across a 5-10 call chain. OpenAI's approach is hardware-dependent (Cerebras partnership) while Anthropic's is a serving configuration change (low batch size trading GPU utilization for latency). Anthropic's fast mode likely costs them more per token to serve, which will eventually show up in pricing.

GPT-5's Tokenizer: ~200K Vocabulary

The GPT-5 tokenizer has been reverse-engineered via OpenAI's tiktoken library, revealing approximately 200,000 tokens — roughly double GPT-4's vocabulary. Larger vocabularies mean fewer tokens per input (reducing per-request cost) but increase embedding table size. Tokenizer design decisions cascade into cost, accuracy, multilingual performance, and hallucination rates — this isn't a minor implementation detail.

ChatGPT Search: A Pattern Worth Studying

ChatGPT Search's architecture reveals a sophisticated orchestration layer: a Sonic classifier (~196ms) gates web retrieval, then fans out one prompt into parallel queries across web, shopping, images, news, and local indices. Results merge via Reciprocal Rank Fusion (RRF) with configurable recency windows (7/30/365 days). RRF doesn't require score normalization across sources, making it ideal for combining results from heterogeneous backends. If you're building RAG or search systems, this fan-out + RRF pattern is directly applicable.

Microsoft's Model Independence Play

Microsoft is actively developing its own AI models under Mustafa Suleyman to reduce OpenAI dependency. This is a long-term architectural risk signal for anyone on Azure OpenAI. Maintain abstraction layers that let you swap model providers without rewriting business logic. The companies that built tight couplings to specific model APIs in 2024 are the ones scrambling in 2026.

Don't chase tokens/sec as a standalone metric — for agentic workflows that chain multiple LLM calls, a 10% accuracy drop per call compounds to 40-65% degradation at the chain level.