EventSauce is an opinionated event sourcing library for PHP that leaves storage to you

Four sentences, and the design decision inside them

The README for EventSauce is unusually short, and what it does say is the whole pitch.

EventSauce is a somewhat opinionated, no-nonsense, and easy way to introduce event sourcing into
PHP projects. It's designed so storage and queueing mechanisms can be chosen based on your

The word that carries the argument is opinionated. Event sourcing in PHP is easy to start badly, and the failure mode is a codebase where the aggregate logic is tangled with a specific storage implementation or a specific message bus. A library that fixes the domain model side and refuses to fix the infrastructure side makes that mistake harder to make by accident.

The second sentence says the same thing from the other direction. Storage and queueing mechanisms can be chosen based on your specific requirements, which means the library defines the contracts and leaves the adapters to the project, or to separate packages, or to your own code.

The third sentence is the part that is easy to miss. It has test tooling, designed to work with an event sourcing mindset. In an event sourced system, the interesting assertions are about the sequence of events that happened, not about the state a database row happens to be in right now, and test tooling that understands that changes what your tests look like.

Then the README ends with two words, that's it, and points to the documentation site. The homepage is eventsauce.io and the documentation lives at eventsauce.io/docs, so the repository is a code drop and the site is the manual.

The repository layout is a map of the library

With so little prose, the tree does the explaining, and it is a well organised one.

The `src/` directory holds the library itself, `tests/` the test suite, and `docs/` the documentation source. Configuration files describe the quality tooling: a `phpunit.xml.dist` for the test runner, a `phpstan.neon` for static analysis, a `.php-cs-fixer.php` for coding standards, and a `.scrutinizer.yml` for the continuous integration service whose badges appear in the README for code quality and coverage.

The presence of `run-tests.sh` at the root tells you there is a single entry point for the suite, which is what a project with multiple PHP versions or multiple dependency sets tends to need.

The most telling file is `config.subsplit-publish.json`. Subsplit is a tool for splitting one repository into several, and the configuration file is how you configure it. Its presence says the project publishes sub-packages, which is consistent with the stated design where storage and queueing are choices: the core stays in one place, and the concrete backends live in their own repositories that share the same source tree.

The `composer.json` at the root is the package manifest, and the README's badges point at the Packagist entry for `eventsauce/eventsauce`, which is the name to require. There is also a `CHANGELOG.md` and a `CONTRIBUTING.md`, which in a project with no release tags become the two documents that matter most for a new user, since the changelog is the de facto version history.

The licence is MIT, with the text in the `LICENSE` file.

No releases, no quickstart, and a documentation site doing the work

Two facts about how this project is distributed are worth stating before anyone plans around it.

The first is that the repository has no GitHub releases. The Packagist badges in the README show the latest stable version and the download count, so the versioned distribution happens through Composer, not through GitHub release artifacts. For a library rather than an application, that is normal, and it means the Composer constraint in your `composer.json` is the thing that pins the version.

The second is that the README contains no installation command and no code example. There is no quickstart, no `composer require` line, no snippet showing an aggregate, an event or a message. The README links to the documentation site and stops there.

That is a real onboarding cost, and it is a documentation problem rather than a design problem. The library's own README says the docs are where the information is, and the repository ships a `docs/` directory, so the documentation source is versioned alongside the code, which is the arrangement you want if you are reading the docs for the version you have installed.

What a reader gets from the repository itself is the vocabulary implied by the file names and the badges. The `phpstan.neon` and `.php-cs-fixer.php` tell you the project holds a static analysis and coding standards line. The `phpunit.xml.dist` and the coverage badge tell you coverage is measured. The Scrutinizer quality score badge tells you the same checks run on every change. For a library that other people will depend on, that is a reasonable signal about the code, and it says nothing about how to use the library, which is what the docs are for.

What the project will not tell you

Since the README is four sentences long, the honest way to evaluate this project is to list what it leaves unanswered, because those are the questions that determine whether it fits your situation.

Which PHP versions are supported is not stated in the repository, and that is the first thing to check, because the library uses modern PHP syntax and the constraint lives in the `composer.json` and in the CI matrix rather than in prose.

Which storage backends exist is not stated either. The design says storage is your choice, and the subsplit configuration implies that some backends are published separately, but the README names none. A team deciding between a relational store and a document store needs to know whether an adapter exists, whether it is maintained, and whether the one that fits is one you will have to write.

The same applies to queueing. The messaging side is part of the design, and the README describes queueing mechanisms as a choice, but it does not say which message brokers are supported, or whether the message contract is the same across them.

The test tooling is mentioned but not explained, so the question of how the library expects you to assert on events is answered only in the documentation. That matters more than it sounds, because the shape of the test API is what a team will feel every day.

Finally, the README does not document how a project migrates an existing database into event sourcing, or how to run event sourced and non event sourced code side by side during a transition. Those are the two questions that most often decide whether a team adopts a library like this at all, and they are not answered in the repository.

A library that is maintained quietly

The maintenance signals are modest and consistent with a mature, stable library rather than a fast moving one.

The repository is not archived, and the last push was on 2026-05-09, so work is still happening on the source. The topic list is short, just event sourcing and PHP, and the recent releases list is empty, which is consistent with a project that versions through Packagist rather than through GitHub tags.

The `CHANGELOG.md` is therefore the place to look for what changed, and its existence is a good sign, since a changelog is a form of commitment to communicating changes to the people who depend on the library. A project that stops shipping tagged releases but keeps a changelog is telling you that the release channel is Packagist and the history is the file.

A `CONTRIBUTING.md` is present too, alongside the `CHANGELOG.md`, the `LICENSE` and the `README.md`. The point worth making is that the project has the ordinary civic files a dependency of other people's production systems should have, which is a low bar but a real one.

The combination of a permissive licence, a documented PHP constraint in the manifest, static analysis, a style fixer and a coverage badge is a coherent picture of a library maintained by someone who expects other people to depend on it, without the noise of a large roadmap.

Where event sourcing fits and where it does not

The honest framing for anyone considering this library is that it is an implementation choice, not an architectural argument.

Event sourcing fits domains where the history is the point. Auditing, billing, ledger-like accounting and any workflow where a question about what happened in the past must be answered exactly are the cases where storing events and projecting state is a real advantage. A library that hands you the aggregate, event and message contracts removes the part of that work that is pure plumbing.

It does not fit a CRUD application with a single interesting transition, and this library will not pretend otherwise. The README itself says no-nonsense, and the cost of event sourcing is a schema of events to version, projections to rebuild, and a mental model that is different from updating a row. A team that adopts it for a simple resource has taken on a cost with no matching benefit.

The alternative worth naming is writing the aggregate and event model yourself on top of your own framework, with the persistence layer you already have. The difference in approach is that EventSauce fixes the contracts and the test tooling, and gives up the ability to choose your own domain model conventions, while a hand rolled version keeps total control and costs you the messaging and testing infrastructure.

For a team that has already decided on event sourcing, and that wants the plumbing settled, this library is a reasonable default rather than a risky one. The evaluation then reduces to checking that it supports your PHP version, that an adapter exists for the storage and queue you run, and that its test model matches how your team wants to write tests.

Editorial conclusion

EventSauce fits a PHP team that has decided to use event sourcing and wants the aggregate, event and message plumbing settled for them while keeping the database and the queue as their own choice. Skip it if you are still deciding whether event sourcing is the right model, since the library will not make that case, and expect to read the documentation site rather than the repository. Verify first that a storage backend and a queue implementation exist for the versions of PHP and your infrastructure you use, since the README names neither, and read the changelog before upgrading, because the project ships no tagged releases.

Frequently asked questions

Official sources

1. EventSaucePHP/EventSauce on GitHub
2. Issues
3. License: MIT
4. Project website
5. README