Event Store Dbal Laravel Package

Product Decisions This Supports

• Build vs. buy for the event store layer itself. Every event-sourced feature needs the same commodity plumbing: an append-only table, an aggregate-version column for optimistic concurrency, and a read path that replays events in order. This package is that plumbing already written; the decision it informs is "do we spend two to four engineer-weeks building and hardening our own append-only store, or adopt ~a few hundred lines of MIT-licensed adapter code and spend that time on domain logic?"
• Committing to event sourcing as an architecture, not just an audit log. Adopting this package is a de facto commitment to Broadway's EventStore interface and its aggregate/repository model. That is a one-way-ish door for the domain layer, so it belongs in the same roadmap conversation as "do we want CQRS read models, temporal queries, and replayable history?"
• Feature bets that require history you can trust. Ledger-style balances, order/fulfilment lifecycle, subscription state machines, compliance audit trails, "what did this record look like on date X" screens. If the roadmap contains any of these, an event store stops being infrastructure trivia and becomes the enabling dependency.
• Data ownership and portability. This writes to plain SQL tables on MySQL/Postgres via Doctrine DBAL. The decision it supports is "our event history lives in our database, in a schema we can read with any SQL client, with no vendor and no proprietary log format" — meaningful for exit strategy, BI access, and legal/retention requirements.
• Deferring the database choice. Because it's DBAL-backed rather than tied to a specific engine, it lets you ship on Postgres today and revisit storage later without re-architecting the domain. It also means the decision to not buy Kafka/EventStoreDB yet is a low-regret one.
• Maintenance posture decision (forced by the archive flag). The package is archived. The real product decision is not "adopt yes/no" but "adopt-and-fork, with a named internal owner and a calendar reminder to review." That is a resourcing decision, and it should be priced into the estimate rather than discovered in month nine.

When to Consider This Package

Adopt when most of these are true:

• You have already chosen Broadway for event sourcing (or are choosing it now and want the SQL persistence layer to match), and you want the reference implementation rather than a bespoke one.
• Your stack is comfortable with Doctrine DBAL — i.e., you are not expecting Eloquent models, and you accept that appends will bypass Laravel's ORM events, casts, and soft deletes.
• You need optimistic concurrency on aggregate version and nothing more exotic — no partitioning, no snapshot automation, no projection framework included.
• You can absorb the archived status: someone owns a fork, the code is small enough to audit, and your team is fine reading its source when something breaks instead of filing an issue.
• Low blast radius: a bounded context, an internal service, or a first event-sourced module where being wrong is recoverable.

Look elsewhere when:

• Greenfield Laravel with no Broadway commitment. spatie/laravel-event-sourcing or patchlevel/event-sourcing give you Eloquent-native projections, migrations, and active maintenance for roughly the same effort. Choosing this package first is choosing a smaller ecosystem for no offsetting gain.
• You need a supported dependency. Archived + ~29 stars is a thin adoption signal: few peers to ask, no upstream fixes, no security response. If procurement or a SOC2-style review requires a maintained supplier, this fails that gate.
• You need capabilities it deliberately omits: snapshots as a first-class feature, projection/read-model management, upcasting of old event versions, multi-tenancy, event streaming to external consumers, or high write throughput beyond what a single SQL table comfortably serves.
• You are not on SQL. If the target is EventStoreDB, Kafka, or DynamoDB, this is the wrong adapter and Broadway's ecosystem here is thin.
• The team will not own a fork. If "archived" translates to "we'll deal with it later," pick an actively maintained alternative now rather than migrating mid-flight.

How to Pitch It (Stakeholders)

To executives: This is a small, free (MIT), plain-SQL component that gives us an audit-grade, replayable history of business events — the foundation for compliance reporting, "state as of date X" answers, and safe retroactive fixes. It stores data in our own database in ordinary tables, so there is no vendor lock-in and no new platform to buy or operate. The honest caveat: the upstream project is archived, so we would take a supported-copy approach — we own a pinned fork of a few hundred lines with a named maintainer. That is a modest, bounded cost, and it is the reason the recommendation is "adopt behind a bounded context with an owner," not "adopt everywhere."

To engineering: It is the DBAL persistence adapter for Broadway's EventStore interface — append, load-by-aggregate, and version-based optimistic concurrency against plain SQL. It is thin, readable, and easy to fork, which matters because it is archived. Pair it with Broadway's snapshot support if replay cost becomes real. Do not expect Eloquent integration; appends go through DBAL, so any ORM side effects need explicit handling. If we are not already sold on Broadway, stop here and evaluate patchlevel/event-sourcing first — the adapter is fine, but the ecosystem around it is the actual risk.