Building a Production-Ready Event Store with PostgreSQL: Lessons from Running It at Scale

Your event-sourced system worked perfectly in development. Then you hit 10 million events, projections started lagging by minutes, and your ops team is asking why the database is consuming 80% CPU during peak hours. Here's how to build an event store that actually survives production. Event sourcing promises an immutable audit log, time-travel debugging, and the ability to rebuild state from scratch. What the tutorials don't mention: most event stores fail not because of architectural flaws, but because of operational neglect. The schema that seemed elegant at 100,000 events becomes a maintenance nightmare at 100 million. The projection that rebuilt in seconds now takes hours. This guide covers the hard-won lessons from running PostgreSQL as an event store at scale—the schema decisions that prevent late-night emergencies, the concurrency patterns that don't deadlock under load, and the operational practices that keep your system healthy. Why PostgreSQL Makes Sense (And When It Doesn't)