What are the practical limitation for get event store?

EventStoreDB
#1

First of all let me say that get event store is a very nice and attractive solution for an event driven architecture.
It embodies alot of features in one tool. Features which you could have used only by assembling several tools and take care of consistencies on your own.

Now to my question, what are the limitations of get event store?

I see there on the website that it can handle 15k writes/sec. What was the configuration / setup for the server or cluster (if a cluster was used)?
What is the number of max nodes a cluster can handle (by handle I mean keep the input and output flow steady) ?
What are the limitation for the projections? Should they be used only for simple queries?

I am more interested for high input/writes volume applications (with steady 100k writes/sec with or without bursts of milions / sec) ? Is event store a practical
solution for these high volume of input streams?

Some benchmarks for free and commercial versions would nice to have on the website.

Thanks for any clarification

#2

First of all let me say that get event store is a very nice and attractive solution for an event driven architecture.
It embodies alot of features in one tool. Features which you could have used only by assembling several tools and take care of consistencies on your own.

Now to my question, what are the limitations of get event store?

I see there on the website that it can handle 15k writes/sec. What was the configuration / setup for the server or cluster (if a cluster was used)?
What is the number of max nodes a cluster can handle (by handle I mean keep the input and output flow steady) ?
What are the limitation for the projections? Should they be used only for simple queries?

I am more interested for high input/writes volume applications (with steady 100k writes/sec with or without bursts of milions / sec) ? Is event store a practical
solution for these high volume of input streams?

Some benchmarks for free and commercial versions would nice to have on the website.

Thanks for any clarification

#3

"I am more interested for high input/writes volume applications (with
steady 100k writes/sec with or without bursts of milions / sec) ? Is
event store a practical
solution for these high volume of input streams?"

Normally you would give up consistency and/or safety in such
situations first before anything else. ES does not do that at this
time. EG things like ACK a message before fsyncing it to disk or using
asynchronous replication

#4

Thanks for the replies. I did not actually understand the problem regarding consistency for a high volume writes scenario. I was more interested at a higher level. Probably I will have to read the event store source code to see what the process flow actually is.
Also when I was refering to taking care of consistency compared to other stacks for implementing event driven architectures (with DDD), I was thinking about the normal stack of some realtional db or nosql db + a messaging queue and maybe esb or transaction coordinator of some sort. With get event store you can forget about maintaining that whole stack. Ofcourse at a first glance :). When I have time probably I will check the code of GES.

Thanks again for the replies. Have a nice day!