Prooph Event Store: the shared contracts behind Prooph's event store implementations

What the package actually contains

The Prooph Event Store repository holds the common classes and interface for Prooph Event Store implementations, and that one sentence is the most important description in the project.

The repository description calls it a PHP 7.4 EventStore Implementation, and the readme is more precise, and the more precise version is the one to plan against. This is a contracts package. It defines the types that an event store implementation provides, and the actual storage and transport live elsewhere.

That shape is the usual one for a library family, and it has a concrete benefit for the consumer: the application code talks to the interface, and the engine behind it changes without the application changing. A team that starts with one implementation and later needs a different one, for a deployment reason or a performance reason, has an interface to switch across rather than a set of calls to rewrite.

The feature list in the Prooph ecosystem is built around that idea, with the topic tags naming cqrs, ddd and event-sourcing, which are the three areas an event store sits at the intersection of. An event store is the append-only side of event sourcing, the read model side is where CQRS comes in, and the aggregate and repository contracts around it are where the domain-driven design vocabulary lives.

The package is released under the New BSD License, the primary language is PHP, and the recent releases are v7.12.3 from 2025-04-21, v7.12.2 from 2026-04-03, and v7.12.1 from 2025-04-02. The last push to the repository was on 2026-05-03.

The two persistent implementations, and how they differ

The documentation lists the available persistent implementations, and the two entries are separated by transport rather than by storage engine.

The Event Store Client is for async TCP connections, and the Event Store HTTP Client is for HTTP connections. Both are separate packages with their own repositories, and the naming convention is consistent with the parent package.

The distinction is not academic. A TCP connection to an event store is a long-lived, ordered, bidirectional channel, and a client that owns one has to deal with reconnection, heartbeats, and the fact that the server may have its own notion of where a stream ended. An HTTP client makes the same calls over request and response, with the server's history API providing the ordered access. The first is faster and more chatty, and the second is easier to run behind a load balancer and to reach from a runtime that cannot hold a raw socket open.

That last point is what decides it for a lot of teams. A PHP application running in a container or on a platform where outbound TCP to a long-lived service is awkward will use the HTTP client, and the interface means the rest of the code does not change.

The repository itself does not contain either client. That is the distinction from the previous section, and it is why the readme's installation instruction is about adding a requirement to composer.json rather than about configuring a database. The configuration work happens in the implementation you choose.

Installing it, and the version table that tells you which line you want

Installation is a Composer requirement, and the documentation gives it as a development branch:

"prooph/event-store": "dev-master"

The dev-master advice is a signal about the project rather than a recommendation. This is a library that is developed in the open with the master branch as the source of truth, and the readme is written for contributors and early adopters as much as for consumers.

The version guidance table is the part to read properly, because it tells you which line is alive and which are history.

| Version | Status | PHP Version | Support Until | |---|---|---|---| | 5.x | EOL | >= 5.5 | EOL | | 6.x | EOL | >= 5.5 | 3 Dec 2017 | | 7.x | Latest | >= 7.4 | active | | 8.x | Development | >= 8.1 | active |

So 5.x and 6.x are end of life, with 6.x's support window closing on 3 December 2017. The 7.x line is the current stable one and requires PHP 7.4 or newer. The 8.x line is under development, requires PHP 8.1 or newer, and is also marked active.

Two things follow. A project on PHP 7.4 or 8.0 can use the 7.x line but not the 8.x development line, and a project on PHP 5.5 or 5.6 is on a version of the library that stopped being supported years ago. And a consumer choosing between the latest stable line and the development line is making a real choice about whether to track unreleased work.

The tooling in the repository supports that choice being made properly. There is a phpunit.xml.dist for the test configuration, a psalm.xml for static analysis, a .php-cs-fixer.php for the code style, a .coveralls.yml for coverage reporting, a .travis.yml for the continuous integration, a .docheader for the file headers, a CHANGELOG.md and the src/ and tests/ directories.

Where the documentation and the community live

The documentation section is short and slightly awkward, and the awkwardness is informative.

It points to the prooph/documentation repository, and then says the documentation will be published on the website soon. So the canonical documentation is in a separate repository, and the website version is not there yet. For a library whose whole value is the shape of its contracts, that is a real gap, because a contract you cannot read is a contract you have to infer from the source.

The support section routes to three places. Questions go to Stack Overflow with the prooph tag, bugs go to the GitHub issue tracker of this repository, and there is a Gitter chat for the whole Prooph community.

Stack Overflow being listed first is a good indicator of the shape of the project. A mature library with a large body of questions accumulates a searchable archive, and a library at version 7.12 with a two-decade-old 5.x line behind it has had time to accumulate one. It also means the questions that were asked and answered are the best available documentation for the parts the readme does not cover, which is most of the contract surface.

The contribute section asks for unit tests with every change and offers the option to adapt the documentation, and the readme invites people to fork and extend existing plugins or add new ones. The word plugins is the one to note, because it is where the library family meets the implementation packages: the shared contracts are extended by implementations that plug into them, and a fork of this package is usually the wrong way to add a feature that belongs in an implementation.

Where Prooph Event Store is the wrong tool

The first limit is that it is not a database, and the readme says so in the second line. There is no persistence here, no schema, no migration story and nothing to configure. A team that wants to store events and read them back needs an implementation package as well, and the choice between them is a deployment decision that this repository does not make for you.

The second is the ecosystem commitment. The contracts are Prooph's, and the implementations are Prooph's, and the whole arrangement assumes you are building the Prooph way, with its aggregate model, its command and query buses and its repository abstractions. Adopting the event store interfaces without the rest of the framework is a way of ending up with Prooph's vocabulary and somebody else's application structure, which is a poor trade.

The third is the version situation. The development line is on PHP 8.1, the stable line on PHP 7.4, and both are marked active while the two older lines are end of life and one of them stopped being supported in 2017. A project has to pick a line, and the 8.x line is by definition not the one most users are on, so a team on PHP 7.4 or 8.0 is pinned to the 7.x line and to whatever the 8.x work eventually produces.

The fourth is the documentation gap, already described. The contracts are the product, the documentation is in another repository, and the website version of it is pending. A library at 7.12 that has been around long enough to have accumulated a Stack Overflow archive has an unusual advantage here, because the questions other people asked are often a better description of a contract than the reference documentation would have been, and that is not a substitute for documentation.

And the fifth is the release rhythm. The last tagged releases are from April 2025 and the last push to the repository was in May 2026, so there is a gap of about a year between a release and the most recent work on the branch. For a stable contracts package that is not alarming, since the interfaces are not supposed to move, but it does mean the pinned version and the current source are different things, and a consumer on a release is not running the code in the repository.

Editorial conclusion

The Prooph Event Store package is worth adopting if you are building an event-sourced PHP application inside the Prooph ecosystem, because it gives you one set of interfaces for the store so that the storage engine becomes a swappable detail, and because the HTTP and TCP client implementations mean the same application code can run against a local process or a remote service. It is the wrong tool if you want a database you can point at, and it is the wrong tool if you are not already using Prooph. Before you install it, check three things: which line you are on, because the version table marks 5.x and 6.x as end of life, 7.x as the latest line requiring PHP 7.4, and 8.x as the development line requiring PHP 8.1; that you are installing a contracts package and not a store, since the documentation is explicit that this repository holds the common classes and interfaces for implementations and the persistent implementations live in separate packages; and that you read the support guidance, because the documentation lives in the prooph/documentation repository rather than here, and the note that it will be published on the website soon tells you the published documentation is not the current one.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. Project website
3. prooph/event-store on GitHub
4. README
5. Releases