EventStoreDB has recently had many improvements due to their growth in team size and the future looks promising for the product. The company has recently announced a new versioning strategy to a date based strategy to make the length of support more intuitive to customers. You can read more at https://www.eventstore.com/blog/new-version-strategy.
Below are 10 reasons on why you should think about upgrading to the latest LTS(long term support) version 20.10.2 (at the time of writing of course).
Information detailed below have been compiled from the release notes at https://www.eventstore.com/blog/release-notes
1. Backport Of Fixes
The October releases are now going to be long term support releases and to be supported for the next 2 years (from the release date). This means that bug fixes will be backported to those versions. As an example, version 20.10.2 contains bug fixes that were backported from 21.2 to improve the product.
2. Cluster Stability Improvements
Cluster stability depends on the nodes’ ability to talk to each other correctly. There are scenarios where an overloaded node can take too long to reply to a gossip message, for example when that message is backed up in the send queue. This has now greatly improved in the latest 20.10.2 with a proactive heartbeat logic implemented which will reduce the number of heartbeat timeouts on busy servers.
Fewer false positives of dead nodes results in fewer fake cluster changes and better cluster stability.
3. Server-Side Filtering
Server side filtering allows you to request events from the server by passing a filter. The advantage in letting the server do the filtering compared to just reading from $all is that you will have significantly less events to receive (less network cost) and filter (less computation) on the client side. You can read more about it here: https://www.eventstore.com/blog/server-side-filtering
4. gRPC Interface
The new gRPC interface allows for easier implementation of clients. So far clients officially(I mean by EventStore) released are the NodeJS, Java, Rust, Golang and DotNet gRPC clients.
5. Read Only Replica
Previously on version 5 we used to have only Masters and Slaves. With version 20.10.2 firstly the terminology has changed from Master to Leader and from Slave to Follower.
In addition to this, it is possible for a node to be to a Read Only Replica. As the name suggests, this node is to used for reads only and the node itself does not take part in the quorum for elections.
Read Only Replica allows you to scale up on reads for catchup subscriptions, although, persistent subscriptions still only run on the Leader node.
6. Improvement In Memory Usage
There have been many memory usage improvements regarding index merges, specially in cases where the index cache depth values had been changed to higher values. Index merges are an essential part of letting a server keep up good performance as it grows and the memory improvements to index merges means that the cluster health is better.
7. Improvement To Projection Subsystem
If you take a look at the public repository and the number of projection fixes that been done over the years, you will realise that the projection subsystem is not much more stable. The likelyhood for projections to fault is now decreased with many corner cases fixed.
https://github.com/EventStore/EventStore/pulls?q=is%3Apr+is%3Aclosed+projection
8. Improvement To Facilitate Maintenance
Version 20.10.2 has the ability to resign a Leader node. What this means is that a new election is triggered with an attempt to elect a new Leader. This is extremely useful for performing maintenance work. By maintenance work we mean scavenging and manual index merges. Both of the those operations are resource intensive and it is recommended that they are performed on the Follower Nodes as the Leader Node is usually busier.
In addition to the above, you can also restart projections and persistent subscriptions subsystems.
9. Performance Improvements
A new option is now available to increase Read Index Cache Capacity. With this option you can increase the amount metadata that is cached by EventStore and increase both read and write performance.
Index memory improvement also mean that index cache depth can now safely be raised to a higher level. This can bring about better performance but it is a value to be used carefully and to be tested first in a development environment.
There is also a commercial option available to bypass check stream access which will also increase both read and write performance (because every write in EventStore has to perform a check on stream access first).
10. DotNet Core 5.0
EventStore has moved from Mono 4.6.2 to Mono 5.16.0.220 in version 5. Then to DotNet Core 3.0 in version 20.6.0. Finally, in version 20.10.2 EventStore has moved to DotNet 5. This brings various overall improvements to the runtime that can be found on the official website at https://dotnet.microsoft.com/download/dotnet/5.0
We hope that all of the above has convinced you to upgrade to the latest EventStoreDB.
