Another solution in the same space is Apache Geode. Its commercial version has been around since a long time and has been well proofen on very large loads in systems that require low response times.

Disclaimer: I work on Geode.

What is the current state of Gemfire/Geode vs GridGain/Ignite? Any big differences?

Also vs snappydata which is based on gemfire?

Worked on GemFire prior to Pivotal acquisition (before Geode) and currently work for SnappyData.

You can imagine GemFire/Gridgain as an apples-to-apples comparison. Both are "enterprise" in-memory data grids originally intended for managing data in low-latency OLTP applications which later added analytics/OLAP features. Geode/Ignite are the open source options for these two IMDGs and also a good apples-to-apples comparison. (Hazelcast also has enterprise/OSS verisons I would compare accordingly)

I can't speak to the current comparison between these systems, but I can compare them to SnappyData. SnappyData deeply integrates GemFire with Spark to bring high concurrency, high availability and mutability to Spark applications. In the world of combining Spark with a datastore over a connector (cassandra, hive, mysql, mongo etc) to enable "database-like" features in Spark, SnappyData has taken the next step of integration. In Snappy, the database (GemFire) and the Spark executors share the same block manager and VM so the systems no longer communicate over a "connector." This, along with our database optimizations, provides the best performance for Spark applciations in what I like to call the "Spark Database Ecosystem."

As such, comparing SnappyData to GemFire/Hazelcast/Gridgain does not make much sense unless you are trying to use Spark in conjunction with these systems. In that case, the main difference I would point out is that SnappyData will necessarily perform better as any of them would need to use a connector to interact with Spark. The better comparison would be between SnappyData and Ignite, as Ignite contains a direct Spark abstraction called "IgniteRDD." That said, the majority of the comparisons/benchmarks we've run have been against MemSQL+Spark and Cassandra+Spark, so I don't have much to say about Ignite vs SnappyData.

User manigandham mentions SnappyData's Approximate Query Processing features (called Synopses Data Engine) which is unique within this space, but a discussion of which would take this too far afield.

1st time coming across snappydata, looks like it's more of a sql execution engine built into/on top of apache spark with a focus on statistical accurate but much faster queries using a margin of error. Pretty neat in itself.

I haven't explored ignite seriously. Care to explain if you mean they implement these kind of features (locks, counters) properly or that they don't try to provide features that their design safely can't.

GridGain, the commercial company behind Ignite, and the community seem to be implementing the features correctly so that they work as advertised, backed up by the case studies and personal accounts I've heard.

Used Ignite on two projects. Was a good match for one, was a poor match for another (not Ignite's fault - poor choice at project outset - did not match initial team's skills or project requirements). In both cases was very impressed with Ignite's docs and community. It works pretty much as advertised/documented - and the GridGain guys really know their stuff. The commercial version - GridGain - has some nicer tooling/ UI capabilities and support - if you have the budget, otherwise the Apache project is solid to build on and well documented.