Google is playing catch up in the cloud wars. That’s not a secret. With AWS already churning out $7.8 billion and Google’s cloud reportedly not due to hit $1 billion until next year, the company needs to do something, and fast.

But what to do? That’s a hard question to answer.

On the one hand, the company is awash in exceptionally innovative technology, even the mere ideas of which have given rise to Apache Hadoop and Mesos. So maybe Google should simply commercialize the great technology that it builds to run its diverse businesses. However, most enterprises don’t, and can’t, run like Google, begging for Google’s cloud to be a bit more pedestrian.

According to a report in The Information, Google is trying to figure out how to offer its internal Spanner database to developers. Spanner is a “scalable, multi-version, globally-distributed, and synchronously-replicated database.” It is, in other words, extraordinarily cool. What it’s not, however, is a mainstream, broadly-adopted database, which prompts the question: Would Google be better off delivering a well-known database like MongoDB or Apache Cassandra?

What the market wants

I’m not completely unbiased in this suggestion, of course. I used to work at MongoDB and still have friends there, just as I have friends at DataStax, the company behind Cassandra.

SEE MongoDB and Cassandra put relational databases on notice (TechRepublic)

But, it’s not really my bias that matters here–it’s the market’s. And the market is heavily biased toward MongoDB and Cassandra, the only two general-purpose NoSQL databases to earn a place in the world’s top 10 most popular databases, as DB-Engines data indicates:

As data becomes “bigger,” these databases will only increase in popularity. Despite well over 100 different NoSQL contenders, nothing else comes close to these two databases in terms of adoption. (DB-Engines’s popularity index uses a variety of data, including job postings requesting a given technology expertise, general interest measured through Google searches, forum mentions, and more.)

Today, Google offers a range of database services, including a MySQL-compatible RDBMS and two NoSQL services, BigTable and Google Cloud Datastore. You’ll find BigTable down at #190 on the DB-Engines index, and Google Cloud Datastore at #111. Meanwhile, Amazon’s different offerings all make the top-100 and keep rising dramatically in terms of popularity–particularly Aurora.

Yet none of these cloud services matches MongoDB or Cassandra in developers’ tool chests. So why not embrace what developers already know, rather than trying to turn internal technology into a winning external product?

It won’t be cheap

Let’s be clear: Turning Spanner into a sellable product will be difficult and expensive. As Steve Nellis and Amir Efrati describe for The Information, “To commercialize Spanner, Google will have to overcome one big problem, which is that the technology is very tightly integrated with all of Google’s proprietary hardware and software systems.” Decoupling Spanner from the Google infrastructure that it depends upon will be non-trivial, to say the least.

SEE Google’s problem with the enterprise cloud is that it’s too innovative and not practical enough (TechRepublic)

It’s similar to what Jeremy Zawodny, then at Yahoo!, said 10 years ago at OSCON about why open sourcing pieces of the company’s technology is hard: “Yahoo’s applications are tightly bound together, making it difficult to open one piece without giving away information about how the remainder is written, or making it useless because knowing 1/10th of the application wouldn’t be helpful (because of all the unknown code).”

Which brings us back to MongoDB and Cassandra. Rather than undergoing so much bother to release internal technology that may or may not be a hit with developers, why not offer technologies that developers already use in droves?

Neither AWS nor Microsoft Azure currently offer either MongoDB or Cassandra as services. With databases increasingly serving as a huge competitive weapon in the public cloud wars, Google should consider giving itself an unfair advantage by building services based on one or both of these popular databases.