The Eventide toolkit supports two backend database implementations of its message store: Postgres and Event Store.

Both Postgres and Event Store support the minimum requirements:

• Write messages to a stream
• Isolate concurrent writes from each other using version-based optimistic locking
• Retrieve messages from a stream, optionally starting from a particular position
• Retrieve messages from a category of streams, optionally starting from a particular position
• Retrieve the last message from a stream
• Support retrieval in batches
• Provide gapless sequences for a message positions within a stream
• Provide sequences, possibly with gaps, for a message positions within a category
• Choosing one versus the other depends on specialized features that each provides for the specific use cases that play to their strengths.

Postgres

The greatest quality that Postgres brings to Eventide is how well-known and well-supported it is. Developers know it. Operators know it. It’s common, ubiquitous, and battle-tested.

Postgres is well-supported by major cloud providers like Amazon Web Services and Google Cloud Platform. The scale and performance capabilities of the Postgres cloud offerings are hard to beat, and would be difficult and costly to attempt to reproduce.

Additionally, messages stored in a Postgres message store are just records stored in a table. If there are use cases for your event data or message data that aren’t provided directly by the Eventide tooling, you can interact with the store just as you would with any other Postgres database. And of course, having Postgres in-place puts some rather powerful features in your hands, like geospatial data and querying, hierarchical data, and JSON document storage and retrieval, and more.

For more on Eventide’s Postgres message store, see:
http://docs.eventide-project.org/user-guide/message-store

When to Choose Postgres

Frankly, you should choose Postgres if you’re already running on Postgres (or similar). If the capabilities of Postgres are already well-suited to your requirements, then it’s very likely that it’s a good choice as a message store for your workloads, and for your team.

The wide array of cloud hosting options can make Postgres a particularly good choice.

Event Store

Event Store is a purpose-built database. It’s made explicitly for event and stream storage and retrieval, and stream transformation and analysis.

It’s a quorum and gossip cluster database that is designed for highly-available operation. As such, there are more operational considerations when using Event Store, and it can require more significant effort both in operations and development.

Not only does Event Store satisfy the necessary minimal basics, it also offers advanced stream analysis and querying features that are otherwise difficult to replicate with SQL or a data analysis pipeline.

Its ability to pipe existing streams through transformation functions that write other streams that you can then consume directly or further transform is remarkable accessory for a database system. It’s just not essential to most applications, and is often already addressed by dedicated data analytics capabilities of teams and tools, and it does come with some tradeoffs in terms of load on the write replication on the cluster when stream writes are triggering yet more stream writes.

Choosing Event Store means that, unless you will be purchasing commercial managed services from the Event Store organization, you will need to deploy, host, operate, and manage the cluster yourself. Operating Event Store can at times be a full-time job.

Eventide’s implementation for Eventide is available only as a commercial offering. While the packages and code are freely-available as MIT-licensed open source, they are only supported only commercial support contract.

We encourage users who need Event Store’s advanced features to get comfortable with the implications of running an Event Store cluster. It can be a daunting choice, but it’s there if you need it, and we can help with the transition. But because it can be a time-consuming proposition under certain circumstances, we require a commercial support contract to do so.

When to Choose Event Store

Event Store isn’t as general-purpose as Postgres. It addresses a narrower set of use cases, especially in terms of availability needs.

Choose Event Store if you need its advanced stream querying and embedded projection capabilities, or if you need availability of the type offered by a quorum and gossip cluster.

A basic guideline for choosing Event Store is whether you already have requirements for the kind of database clustering and availability similar to databases like Cassandra or Riak.

Conclusion

In conclusion, use the Postgres message store if your typical database requirements have not already pushed you in the direction of something like Cassandra. If you’re not sure, then Postgres is probably the right place to start.

If you already know that you need the availability profile of something like Cassandra, or if the advanced stream analysis and projection capabilities that are unique to Event Store, then it is worth your time to consider. The Event Store implementation of Eventide also requires a commercial support contract.