Depends on the sizing I believe. One problem I see in Java-based DB like Cassandra and Elasticsearch is JVM busy doing garbage collection. The major collection kicks in all the time. Probably because of bad config and bad data usage pattern, but it is still a common problem for me. I am all ears for advice.
This was an anti-pattern of the runtime model that Java inherited from Smalltalk. Tuning the GC used to be an arcane art. There was also a lot of effort put in by programming shops to just reducing GC pressure as an optimization. This is why I appreciate Golang's pragmatic approach of not using the GC by avoiding the heap. The main benefit to having GC is to make initial development faster by reducing the severity and frequency of mistakes. It's really there as a safety net, not as a foolproof end-all be-all. Use tools in a way which plays up their strengths.
It's hard to tune a GC to be super-fast. It's easy to profile and find your biggest memory leaks.
How much free space is there after a collection? The garbage collector benefits a lot from having enough extra free space to keep things with medium lifetimes in the first generation.
The issue I observed was the both gen filled out very quickly so there was no chance for the minor to complete and just skip to major. But because the gens are consistently filled up, the JVM became "locked" doing full GC.
