When Your Event-Sourced Architecture Outgrows PostgreSQL and Needs a Purpose-Built Store

Teams building with the event sourcing pattern often start with PostgreSQL. It is familiar, well-supported, and can model append-only event streams with a narrow table design. At some volume of streams, events, or concurrent readers, PostgreSQL’s general-purpose architecture becomes the constraint. This article maps the operational thresholds that push teams toward a purpose-built event sourcing database, compares two established options—KurrentDB (formerly EventStoreDB) and Axon Server—and provides a version-anchored migration checklist.

The PostgreSQL Comfort Zone and Its Edges

PostgreSQL handles event sourcing adequately when:

• Event volumes remain in the tens of millions, not billions
• Stream counts stay below the point where index bloat degrades append latency
• Concurrent read-model projections number in single digits, not tens
• Event replay is occasional, not a standard operational procedure

The friction points arrive predictably. Append-only tables in PostgreSQL still generate dead tuples and require vacuuming. Long-running event replays hold back the xmin horizon and bloat storage. Each projection requires either polling (inefficient) or logical replication setup (operationally complex). There is no native concept of stream ordering guarantees across aggregates, so concurrency control falls to application code.

Published third-party benchmarks report that existing database benchmarking tools do not adequately address the unique demands of event sourcing systems. Academic research notes that numerous aspects of event sourcing remain unexplored by scientific investigation. This gap means teams often discover PostgreSQL’s limits through production incidents rather than predictive testing.

What a Purpose-Built Event Store Provides

A dedicated event sourcing database implements four capabilities that PostgreSQL approximates poorly:

Capability	PostgreSQL Approach	Purpose-Built Store Approach
Stream ordering	Application-level optimistic concurrency	Native stream-level expected-version checks
Event publishing	Polling or logical replication	Push-based subscription over persistent connections
Replay optimization	Full table scans with filtering	Indexed stream ranges, checkpointed reads
Schema evolution	Manual migration scripts	Built-in event type versioning and upcasting

The move to a purpose-built store is a database migration in the architectural sense, not merely a data transfer. Read models, projection logic, and command-handling paths all require adjustment.

Option 1: KurrentDB (EventStoreDB)

KurrentDB, previously EventStoreDB, is the open-source event-native database developed by Kurrent (formerly Event Store). The vendor’s official documentation states that EventStoreDB version 23.10.0 LTS was available for both OSS and commercial users and supported through to October 2025. Current KurrentDB versions follow a revised scheme: LTS releases carry even major numbers, while STS (short-term support) versions start with odd major numbers.

The vendor’s official product page describes KurrentDB as built for distributed, intelligent, and real-time systems, with a free trial available. For self-managed deployments, Kurrent Enterprise offers Kubernetes automation, compliance tools, and 24/7 expert support with a 30-day trial.

Who KurrentDB is wrong for

• Teams requiring full SQL ecosystem compatibility (BI tools, ad-hoc analytics)
• Organizations with strict Java-only infrastructure standards (KurrentDB is .NET/Core-based)
• Projects where operational overhead of a new database category outweighs stream volume needs

Option 2: Axon Server

Axon Server is AxonIQ’s flagship product, built from scratch in Java specifically for event sourcing requirements. The vendor’s official documentation states that Axon Framework is open source and always free. Axon Server comes in two versions: Standard (single node, single context) and Enterprise (multi-node, multi-context).

The vendor’s release notes indicate that Axon Server receives a major release three times per year, with versioning aligned to the release year. Axon Framework 4 has long-term support available for existing customers. Release 5.4.0 was not yet shipped as of 2026-10-06.

Axon Server provides immutable event logs with full business context, targeting financial services, healthcare, and critical infrastructure where audit completeness is mandatory.

Who Axon Server is wrong for

• Teams not using or planning to use Axon Framework (tight coupling to the ecosystem)
• Organizations requiring multi-language client support as a primary concern
• Projects where the AxonIQ licensing model conflicts with distribution requirements

Comparative Positioning

Factor	KurrentDB	Axon Server
Primary language runtime	.NET/Core	Java
Framework coupling	Loose (gRPC/HTTP clients available)	Tight (Axon Framework optimized)
Licensing	Open source + commercial support tiers	Open source framework; server has Standard/Enterprise tiers
Release cadence	LTS/STS alternating	Three major releases yearly
Notable strength	Stream-native indexing and projections	Integrated messaging and command routing

Published third-party benchmark repositories report efforts to establish fair comparisons between KurrentDB, Axon Server, and UmaDB by standardizing low-level transport settings and client instantiation strategies. These benchmarks are community-maintained; vendor documentation does not publish head-to-head performance figures.

Migration Path: PostgreSQL to Purpose-Built Store

Pre-migration inventory

Before selecting a target, audit your current PostgreSQL event store:

1. Count distinct streams and total events
2. Measure append latency at p50, p95, p99
3. Identify all active projections and their replay frequency
4. Document event schema versions and upcasting logic
5. Catalog downstream consumers and their coupling to PostgreSQL-specific delivery mechanisms

Version-anchored migration checklist

The following steps assume KurrentDB 23.10 LTS or Axon Server 2026.x as targets. Adapt for your selected version.

Step 1: Establish dual-write path

Deploy the target event store alongside PostgreSQL. Write all new events to both systems. Do not yet read from the target.

Step 2: Back up first

Before any irreversible configuration change, create a complete backup of your PostgreSQL event store and verify restore capability. For PostgreSQL, this means a tested pg_dump or base backup with WAL archiving, plus confirmation that your largest stream restores within recovery time objectives.

Step 3: Historical migration

Export historical events from PostgreSQL in commit order. Transform to the target store’s event format (KurrentDB requires JSON metadata and data payloads with event type headers; Axon Server uses its serialized event structure).

KurrentDB 23.10 LTS documentation: Use the HTTP API or .NET client AppendToStreamAsync with ExpectedVersion.Any for bulk imports. Batch in chunks of 500–1000 events to avoid timeout pressure.

Axon Server 2026.x documentation: Use the Axon Framework EventStore interface or the gRPC admin API for bulk import. The vendor’s release notes note enhanced diagnostics packages for troubleshooting replication group issues during large transfers.

Step 4: Projection replay and validation

Replay all projections against the target store. Compare output state with PostgreSQL-derived read models. Discrepancies indicate ordering or serialization differences.

Step 5: Consumer cutover

Migrate downstream consumers to read from the target store’s subscription mechanism. KurrentDB provides catch-up subscriptions and persistent subscriptions; Axon Server provides tracking event processors and pooled event processors.

Step 6: PostgreSQL decommission

After a validation period (qualitative: typically measured in weeks for high-assurance systems), terminate dual writes and archive PostgreSQL data per retention policy.

Doc-vs-Reality Drift to Flag

Multiple sources present naming and versioning inconsistencies that affect command accuracy:

• KurrentDB vs. EventStoreDB: The vendor has rebranded; documentation and release notes use both names. Commands and package names may still reference EventStore in code while marketing uses KurrentDB.
• Version scheme discontinuity: EventStoreDB used a different versioning pattern (LTS at minor version 10) than current KurrentDB (even major for LTS, odd for STS). Third-party guides referencing “EventStoreDB 21.x” or “23.10” may not clarify which scheme applies.
• Axon Server vs. AxonDB: Historical InfoQ coverage references “AxonDB” as a new implementation; current vendor documentation uses “Axon Server” exclusively. The underlying product is the same, but command paths differ.
• Axon Framework 5.4.0 status: The vendor’s GitHub release notes explicitly state that 5.4.0 was not yet shipped as of 2026-10-06. Any guide assuming this version’s availability is premature.

Operational Considerations Post-Migration

Purpose-built event stores shift operational complexity rather than eliminating it.

Concern	PostgreSQL	KurrentDB / Axon Server
Backup/restore	Mature ecosystem (pg_basebackup, WAL-E, Barman)	Store-specific cluster snapshots and log archiving
Monitoring	Standard PostgreSQL metrics	Custom stream metrics, subscription lag, projection checkpoint tracking
Operational expertise	Widely available	Specialized; training or vendor support typically required
Hosting flexibility	Self-hosted, managed (RDS, etc.), serverless	Self-managed or vendor-managed; cloud options vary

The vendor’s official pricing page for KurrentDB lists commercial support plans with a range of SLAs. AxonIQ’s pricing page indicates Axon Server Standard and Enterprise functionality tiers. For current dollar amounts, check the vendor’s current pricing page—figures are not reproduced here as they fluctuate with plan changes.

Visit Supabase’s official site

Visit DigitalOcean’s official site

Conclusion

PostgreSQL remains viable for event sourcing at moderate scale. The migration to a purpose-built event sourcing database becomes justified when native stream ordering, push-based subscriptions, and optimized replay become operational requirements rather than optimizations.

KurrentDB and Axon Server represent distinct ecosystem bets: KurrentDB for .NET-fluent teams prioritizing stream-native operations, Axon Server for Java-centric organizations already invested in Axon Framework. Neither provides universal advantage; the selection depends on existing language commitments, operational expertise, and the specific volume thresholds your PostgreSQL instance has reached.

Execute migration with version-anchored commands, verified backups before irreversible steps, and explicit validation of projection parity. The event sourcing pattern’s durability promises depend on correct implementation at every layer—including the migration path between stores.