Eugene Ciurana Official Site

NoSQL Done Weird: GeoSpock

I just learned about a NoSQL database called GeoSpock, and was asked why it wasn't featured in my recent NoSQL Refcard.  Here's an introductory video:

The merits of the database are questionable, at least based on the presentation.  Comparing against MongoDB makes no sense. They picked the DB that is the most opposite to what they do to draw the comparison in the best possible light.  It's almost like they thought, "MongoDB has mind share, let's compare our offering against theirs."  It's like comparing a Ferrari to a boat and checking which will do best in a rally competition through muddy terrain.

The biggest problem with the video, though, was that the demo is contrived and doesn't quite show any advantages of GeoSpock over anything else that already exists.

I researched as much about the latest trends in NoSQL databases while producing my latest Refcard, NoSQL and Data Scalability 2.0.  GeoSpock didn't come up in any of the sources that we reviewed, which is surprising for a database that claims to already have an installed base.

GeoSpock Technology Impressions

  • GeoSpock's API isn't doing anything that Couchbase Server, Spark, etc. don't already do, with more stable APIs and a much larger installed user base.
    • By the way, where are the native bindings for popular languages?  REST is beautiful.  REST is good.  REST is a pain for non-trivial implementations.  GeoSpock would benefit from having bindings for the languages most common in data science, scalability, mining, and knowledge discovery:
      • Python
      • Java
  • It's cloud based only, database-as-a-service (DBaaS); that's not a good thing for a brand new DB because all optimizations must be coordinated with GeoSpock's support, since they are opaque to the app developers.  90% of the hard work in making a database fly is optimizing it, not using it.
  • On the geospatial API front, Couchbase Server and others have very robust APIs in place. Couchbase is also exposed through RESTful + native interfaces APIs, and it supports spatial data and queries. It even supports the creation of spatial data structures that aren't based on strict geography or geometry (e.g. you create a "2D- or 3D space" much like you would with spreadsheets).
  • GeoSpock doesn't seem to have a caching model either, so query results optimization falls to the end user. And they don't appear to have any native APIs to wrap their RESTful calls.
  • The source code is closed, so no way of figuring out what they're doing and how their implementation works. Pursuing a closed source, service-only strategy is dicey with a database. Developers like being able to report/fix bugs understanding how things work (for example, we identified a critical bug on MongoDB during Summly days, and I submitted a fix for it -- because we had access to the code).
  • GeoSpock is not listed in Wikipedia's NoSQL or Big Data pages, even though Wikipedia lists databases from many other start ups, commercial, and open source, even some very obscure tools.


I'd advise the team behind GeoSpock to open their database technology more; not necessarily the code, but make it more transparent for potential users to understand the implementation, strengths, and weaknesses.  Savvy users will want to see how it rates against databases with the same general use cases, specially Spark and Couchbase Server.  Based on the information available regarding GeoSpock, I'd say that it's too soon to consider it for actual use.

Do you know anyone who wants to learn the basics of NoSQL and data scalability?  Brewer's CAP theorem, computational networks, high volume data storage, document vs graph vs column vs hybrid databases, and more, via the DZone scalability library:


Written by Eugene Ciurana on Thursday June 18, 2015
Permalink -

« NoSQL and Data Scalability 2.0 - Things People Decide Within 8 Seconds of Meeting You »