- What is ecotone/pdo-event-sourcing and what does it do?
- It is the PDO persistence adapter for Ecotone that stores event streams in the relational database you already run, supporting event-sourced aggregates, event-sourced sagas, projections, upcasting and replay. It requires no additional stateful infrastructure beyond PostgreSQL or MySQL. Note that this GitHub repository is a read-only split of the ecotone-dev monorepo, so adoption should be assessed against upstream ecotone/ecotone rather than this mirror's star count.
- How do I install ecotone/pdo-event-sourcing with Composer?
- Install it with composer require ecotone/pdo-event-sourcing, and make sure the version you pin is aligned with your Ecotone core version since the store is version-locked to it. You need PHP 8 because the API is driven by PHP 8 attributes, plus a real PostgreSQL or MySQL instance where the database user has DDL rights so tables can be created on first boot. Confirm the supported version matrix explicitly rather than inferring it from badges.
- Does ecotone/pdo-event-sourcing work with Laravel?
- It is not a Laravel-specific package: Ecotone brings its own bootstrapping and container integration, and this store talks PDO directly, bypassing Eloquent, the DB facade and Laravel's connection and transaction management. That is a deliberate portability choice, but it means your team owns a seam with two connection paths and two transaction semantics. Verify version alignment between Ecotone core, this store and whichever Laravel integration package you adopt before committing.
- Which databases are supported, and can I use SQLite?
- PostgreSQL and MySQL are supported out of the box. SQLite should be assumed unsupported outside tests, so do not prototype on Laravel's default SQLite setup and report a false blocker. Plan for a real PostgreSQL or MySQL instance with DDL rights from the first boot.
- Do I need EventStoreDB or Kafka to use this?
- No. The whole point of the PDO store is that the event stream lives in the relational database you already operate, which removes the need to introduce and run a second stateful system as the system of record. A message broker only comes into play if you opt into streaming projections that push events to Kafka or RabbitMQ in real time. For plain event-sourced aggregates, sagas and catch-up projections, MySQL or PostgreSQL is enough.
- How do I test event-sourced code without a database?
- Use EcotoneLite::bootstrapFlowTesting to spin up the event store in memory, replay events into your projections and assert on the results, with no external infrastructure required. This is the same testing story as the rest of Ecotone and is well suited to fast unit-level feedback. Be aware the in-memory harness behaves differently from production, so also run a deliberate contention test against real MySQL or PostgreSQL before shipping.
- How does event versioning and upcasting work in this package?
- Events are versioned and upcasters transform older payloads into the current schema when the stream is read, so you can evolve event shapes without rewriting history. The catch is permanence: once events are in the table, every payload schema change requires an upcaster. Treat upcasting as an ongoing design-time commitment that outlives any individual feature team, not a one-off migration.
- What are the concurrency and production risks with a PDO event store?
- Optimistic concurrency on aggregate version, transaction boundary placement and retry-on-conflict semantics are the failure modes that cause silent data corruption in event stores. Ecotone applies optimistic locking on aggregate version, but the transaction boundaries and retry policy around your handlers are yours to own. Validate with a deliberate contention test rather than a happy-path demo, and write replay and projection operations runbooks before go-live.
- How do projections work, including catch-up and streaming variants?
- Declare a projection with the Projection attribute and choose a catch-up, reset, partition or streaming variant. Catch-up projections replay from the stored event stream and can be reset and rebuilt, while streaming projections process events in real time through a message broker transport. Partitioning lets you parallelize projection work across streams, but projection operations and replay procedures remain your team's responsibility in production.
- Is ecotone/pdo-event-sourcing production-ready, and what are the licensing and support risks?
- The feature surface is production-grade, but the package metadata reports the license as NOASSERTION, which should be treated as a release blocker until cleared; the upstream badge points to MIT, so this is almost certainly a split-process artifact. There is a small maintainer base and no visible commercial SLA, so budget for upstream engagement through the ecotone-dev monorepo, since this repository is read-only and cannot be casually vendor-patched. Audit the documentation at ecotone.tech before committing, and scope the package as critical-path infrastructure rather than a utility library.