I can answer some of your questions about EventStoreDB.

Is it a clustered/replicated database?

Yes, the ESDB cluster is a single-leader replica set like MongoDB.

How does it scale (both compute and storage) horizontally?

No, and it's by design. ESDB has a single log, so all the events for the whole system (whatever it might be) that uses the ESDB cluster are ordered. The multilog feature is considered, but not in immediate plans.

Does it support tired storage?

No, not yet.

Can I archive old events easily?

We consider the archive function orthogonal to the database product. It is quite easy to implement, and there are tools for that https://eventuous.dev/docs/persistence/aggregate-store/#multi-tier-store

Is it optimised for reads or writes?

We aim to support fast writes, but reading "hot" (recently written) events is also optimised.

Can I choose between consistency and availability?

No, ESDB is fully consistent, and writes must be acknowledged by the cluster consensus.

One essential attribute for an event store for me is the ability to support real-time subscriptions. Your article gives hints about using external tools (like Debezium) to avoid two-phase commits. It's essential for CQRS implementation (read, or query, models) and integration (external events), and ESDB supports real-time subscription with instant event delivery out of the box. It's something that none of the mentioned stores support without writing additional code or using external tools.

The single log feature that prevents ESDB from being horizontally scalable can also be seen as an advantage. In "pure" world we can say that the order of events between aggregate streams isn't important, but in real like (being pragmatic), the concept of "what happened before" is essential, and having all the events ordered globally makes implementing a lot of use cases much easier. You won't need so much orchestration using process managers if you know that what happened before is literally stored before, so you get it first (when using a subscription). When aggregate streams are spread across multiple tables or collections, and those tables are partitioned, the global order will be lost, and cross-aggregate, or cross-aggregte-type subscriptions would be hard or impossible to implement. When being pragmatic, this becomes a burden. Depending on the size of the system, the single log might become an obstacle, but I'd only consider it as a problem for really large systems. I reality, most systems out there are small to medium, and ESDB can easily support a system with billions of events and millions of writes per day.

When it comes to operations, I would suggest looking at Event Store Cloud (https://www.eventstore.com/event-store-cloud).