Moving from relational data to events
Advocates of event sourcing argue that storing every change as an immutable stream of events can preserve business history, enable powerful analytics, and decouple services, but many engineers in this thread see it as an overused, niche pattern that often adds complexity without clear benefit. Commenters stress that relational databases already support temporal and audit capabilities, and that most successful “event-driven” systems in practice still rely on conventional SQL stores or projections for querying and consistency. The emerging consensus is that event sourcing is valuable for specific domains like finance, analytics, or complex workflows, but is a poor default replacement for CRUD-based relational models.
Overall sentiment about the article
- Many readers found the article unclear, overconfident, and stylistically grating.
- Main criticism: it implies event sourcing should “replace” CRUD/relational approaches without rigorously explaining trade‑offs, pros/cons, or concrete migration steps.
- Some liked the general direction (thinking in events/behaviors) but felt the piece was a shallow or confusing introduction.
Event sourcing vs relational/temporal databases
- Multiple commenters stress that event sourcing and the relational model are orthogonal: you can do event sourcing on top of SQL databases.
- Relational databases already support temporal patterns (e.g., audit tables, journals, SQL:2011 features).
- Datalog and related systems are noted as fully relational and capable of temporal/event-style use.
- Bitemporal concerns arise: some tools only track transaction time, not real “event time.”
Perceived benefits / appropriate use cases
- Good fit cited for: analytics/logging, financial/journal-style data, complex workflows, multi-system synchronization, debugging past behavior, and the ability to rebuild or reinterpret derived views.
- Some report success combining event sourcing, DDD, CQRS, microservices, and projections into relational/search stores.
- Others argue a simple relational DB plus auxiliary history tables or audit logs is enough for most products.
Critiques, risks, and failure stories
- Many see event sourcing as niche and overused; often a “solution looking for a problem.”
- Common pain points:
- High complexity in debugging, mapping/reducing events into state, maintenance, and schema evolution.
- Slow aggregations leading to cached/materialized views, with lag and eventual-consistency issues.
- GDPR and data-retention conflicts with immutable logs.
- Storage and infrastructure cost when “never delete events” meets long lifetimes.
- One detailed war story: an ES+CQRS system with Elasticsearch projections, no deletion, huge cost, extreme import slowness, and only a handful of users—now being reverted to simpler ACID relational designs.
Implementation patterns discussed
- Typical event-store schema in SQL: event id, aggregate id, sequence/version, type, timestamp, JSONB payload; indexed by aggregate and sometimes JSON fields.
- Use of snapshots to avoid replaying full history; projections to multiple read models (relational, key-value, search).
- Some advocate treating the relational DB as a “cache” over an event log; others invert it and just add event tables/audit logs to a primarily relational system.
- For workflow-style problems, durable workflow engines (e.g., Temporal/durable functions) are mentioned as alternatives that internally use event sourcing.
Meta: HN voting dynamics
- Commenters note the post reached the top of HN with mostly negative comments, attributing this to title-driven upvotes, inability to downvote submissions, and people upvoting to keep the discussion visible.