[jhgb]

Gemstone/S is a "classic" Smalltalk-based object database developed by GemTalk Systems. On the other hand, Gemfire, courtesy of VMWare, seems to be something completely different: https://gemfire.docs.pivotal.io/96/gemfire/getting_started/g...

I have no idea how you can draw similarities between the two. One of them is basically a Smalltalk VM with automatic object persistence. The other is some kind of real-time Java-based distributed key/value data platform.

[evanweaver]

As far as I can tell, GemStone/S doesn't offer any server-side partitioning, clustering, or replication. GemFire was developed to scale the GemStone/S patterns horizontally.

The GemStone transaction docs describe a scheme that would work properly on a single machine, but don't discuss anything about distributed coordination across servers or failure modes. The installation instructions don't discuss setting up a cluster. The marketing docs discuss using thousands of VMs (clients) and scaling the dataset to "hundreds of gigabytes" based on disk storage instead of memory which is not what I would expect from a distributed system. Various benchmarks and user comments refer to using a single server for GemStone.

I will update the post to clarify that we are discussing distributed document databases only. It's easy to do anything you want on a single machine.

[jhgb]

But of course I didn't say anything about partitioned and replicated systems, only about the options for document databases. The article of course is about "transaction models in document databases" and the observation that "document databases are very convenient for modern application development, because modern application frameworks and languages are also based on semi-structured objects", which Gemstone/S's model fits nicely since it's based on the same assumption.