Guest post When Salesforce.com announced its database-in-the-cloud service, Database.com, at Dreamforce last month, I suggested smaller PaaS vendors might get squished. Unsurprisingly, those who read my remarkswere none too pleased. Matt McAdams, CEO of TrackVia, was so incensed he sat down and wrote the following, which in the interests of balance, I’ve agreed to publish as a guest post.
Last month Salesforce.com announced its new cloud database service, called Database.com. Or rather, the vendor pre-announced it — it’s not actually available yet, and won’t be until an undisclosed date in 2011. When it is available, it will be a minor addition to the database-as-a-service (DaaS) market, but clearly inferior to other existing offerings.
If you dig beneath the PR spin and examine the technical details published at Database.com, you’ll realize this is not new technology. Rather, Salesforce.com is making the existing database that currently underlies its CRM and Force.com platforms accessible to subscribers who don’t have accounts on one of those two platforms. The target audience is programmers who want to build an application outside of Force.com, but want a hosted database.
Unfortunately, web application developers will find the idea of hosting their data outside their application platform severely unappealing. The reason is latency.
In any web application, when a user clicks a button in the web app, an HTTP or AJAX request is sent across the public Internet to wherever the app code is hosted. Salesforce.com suggests this could be in Google’s AppEngine, Microsoft’s Azure, or Amazon’s EC2, among others. The app code then consults the database to retrieve information, usually a half-dozen or more times, and the resulting HTML or JSON response is sent back across the public Internet to the user’s browser. If the database and the application code are in the same location, then only two public Internet traversals are required to complete the request. If the database and the application code are in different locations, then more than a dozen public Internet traversals are required to complete the request.
Since these traversals are usually the bulk of the wait time for any web app, the app built on Amazon but storing data in Database.com will run at perhaps one tenth the speed (that is, page loads will take ten times longer) than a web app whose code and data are collocated. It’s a non-starter.
The conclusion is, people building apps on Google, Amazon or Azure will use those platforms’ native, local database services. People who use Force.com (or VMForce or Heroku) will use Database.com, but they already do — there’s nothing new there.
Database.com will do better with developers of mobile apps, which contain the user interface and the app code in the same bundle. For mobile apps that need to store data remotely (for example to sync data across devices), Database.com won’t have a latency disadvantage over any other cloud DB. However, in this scenario, Database.com has a different, equally severe disadvantage: it doesn’t support structured query language, or SQL.
Despite the buzz the contrarian no-SQL movement has been getting, the fact is the vast majority of apps and app developers still use relational databases that support SQL. Database.com doesn’t, at least not without the purchase of third-party drivers. Nor does it support cross-table joins, a bread-and-butter query type for any non-trivial app. So Database.com is inferior to other DaaS offerings that do support SQL and joins, like Amazon’s Relational Database Service, FathomDB, or Xeround.
This doesn’t mean that Database.com is without anything innovative. The visual schema designer looks slick. Also cool is the integrated permission feature, in which a user ID can be included in a query, and the rows returned are automatically filtered to only include those the user should have permission to see. More puzzling is the feature that provides a social feed of data rows changed; this is technically cool, but the actual value of sending feed updates on a row-by-row basis from the database instead of from the application layer is a head-scratcher.
The bigger criticism applies to all DaaS offerings, and it’s this: they’re solving the wrong problem. Making databases more accessible to programmers who already know how to use databases is nice and all, but how about making databases more accessible to business users? Why not let non-programmers build web apps without writing code? To do this, Database.com would have to include things that Salesforce.com discloses explicitly are not part of the platform: page layout tools, reports, dashboards, and so on. These can be built with Force.com, but using Force.com requires programming knowledge.
It seems to me the more innovative cloud DB players are the companies providing a cloud database with a complete, integrated app development platform that requires no coding, only point-and-click configuration. These platforms, like TrackVia (the author’s company) or Intuit’s QuickBase, are doing more to change how cloud apps get built than the better-known DaaS vendors are.
In summary, Database.com promises a few interesting features, but it’s hard to see why it’s a better platform than existing offerings. It’s certainly not going to put Oracle out of business. The best part may be the domain name.
