nice name, shame about the platform nice name, shame about the platform

Summary: This guest post explains why's new service won't shake up the PaaS market, despite what you may have read on this blog last month. Contributed by PaaS vendor TrackVia's CEO Matt McAdams.


Guest post When announced its database-in-the-cloud service,, at Dreamforce last month, I suggested smaller PaaS vendors might get squished. Unsurprisingly, those who read my remarks were 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 announced its new cloud database service, called 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, you'll realize this is not new technology. Rather, is making the existing database that currently underlies its CRM and 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, 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. 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 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 (or VMForce or Heroku) will use, but they already do — there's nothing new there. 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), won't have a latency disadvantage over any other cloud DB. However, in this scenario, 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. 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 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 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, would have to include things that discloses explicitly are not part of the platform: page layout tools, reports, dashboards, and so on. These can be built with, but using 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, 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.

Topics: Enterprise Software, Data Centers, Data Management, Hardware, Software, Storage

Phil Wainewright

About Phil Wainewright

Since 1998, Phil Wainewright has been a thought leader in cloud computing as a blogger, analyst and consultant.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Point and Click

    Great post. Pretty much my thoughts too, the developer is not struggling with the db side, he is a DEVELOPER for goodness sake. So abstracting it a bit like salesforce are doing is pointless. And I like the way you have deep-dived into it here - it seems the DaaS market already has more mature offerings.

    However, where you say 'These can be built with, but using requires programming knowledge', this is not really correct. The platform has the option for coding, but a non-developer can point and click their way to a decent application without coding. Just a small point, so I think serves the purpose for people who want to develop apps but are not coders.
  • RE: nice name, shame about the platform

    Couldn't agree more with this post. Any developer with half a brain knows that you keep the data as close to the application as possible. In the same box is best. In the same rack is ok. On a SAN if you must. But on a box 5,000 miles away? You'd have to be mad. Or have very, very patient users.
  • Another way to think of it...

    You are correct when considering typical three tier application design. The request goes from the browser to the web server to the cloud database. Latency between each hop means that the user waits

    An emerging pattern is to load a somewhat static page from the server and then have the page make requests directly to the database. Data is returned in JSON or XML and the javascript on the page builds the interface with something like JQuery.

    Take a look at Couch DB and the Couch App model for more information.
    Ken Richard
  • "Since 1998 ... cloud computing"

    "Since 1998, Phil Wainewright has been a thought leader in cloud computing as a blogger, analyst and consultant."

    Cloud computing in 1998?
  • RE: nice name, shame about the platform

    I'm currently working on a site on Heroku that uses QuickBase as the 'backend' DB. The HTML is all in QB records but cached on the server; the records are of course in QB, but cached in sessions as much as possible, and I could be writing to QuickBase on separate threads ('workers') if necessary. The latency is very acceptable plus I get the power of non-technical QuickBase users being able to manipulate aspects of the site.
  • Best Article Yet.

    Basically it all makes sense and is written without showing a blatant bias towards cloud computing.<br><br>-Edit-<br>Oh! This was a guest post. Wow Phil, nothing like getting credibility for your blog by posting someone else's well written article.
  • RE: nice name, shame about the platform

    A couple points:
    1) Although I am not a developer, I led the build of a distributed application (app layer separate from data-layer and in some cases leveraging multiple app components and different dbs into the same ui) leveraging SFDC (2007) and my firm's proprietary services. As far as performance is concerned, it wasn't an issue. If you build it right we saw sub 500 ms page loads in a dev environment. In limited production, I believe we were consistently around 300 ms. That's good enough for most users and we were building for financial professionals who have a higher demand on performance than a consumer
    2) Agreed if you leverage the public internet, you will have 'standard to sub-standard' performance. You also have security risks and other important issues that would steer you away from the architecture seems to lead you. However, what about private networks?

    For the enterprise, leveraging private networks with connectivity to as a data host, with apps living in private clouds and/or enclosed within a private network such as that offered by Savvis or BT for example, suddenly make more sense. As well, should hard-line or wifi bandwidth deployment not keep pace with demand, high-priority traffic will need to go somewhere. Enterprises might take a look at the cost/efficiency gains of leveraging private networks with a distributed/cloud architecture to gain a better return than running it all publicly and themselves.

    Just a thought....