I live in the Netherlands (some of you may call it Holland) and I do believe we have a superb internet connectivity. By now most parts of our beloved country have a 4G super fast mobile network allowing to work nearly everywhere with a bandwidth that allows HD television on a tablet. Even here companies are quite reluctant to move their business into the cloud. If you look at the technical possibilities the are no barriers, take for example the cloud based BI solution offered by Birst.

But it requires a whole different way of thinking to view a database as a service and not as a resource. In most cases using a connection with limited bandwidth for INSERT and UPDATE statements will not slow down the application enough to be noticeable. However for queries using SELECT it is a completely different story. Most developers will only replace the notorious SELECT * FROM ... with a set of named columns when the expected number of rows is really huge. Sucking all the data into the application server and then decide what to use is so common that some applications even need a database service on the same server to avoid the network overhead. Sometimes you cannot blame the developer, the ORM might access data 'one object at a time' thereby generating loads of tiny SELECT requests for all columns of a single table row. For queries the YAGNI design rule (You Ain't Gonna Need It) clearly does not apply.

As soon as each SELECT request is kept as small as possible the amount of data an application needs becomes manageable. Then it might be possible to move de database into the cloud because the extra overhead does not significantly slow down the application. That requires a different approach to data access for both the developer and the ORM he uses, with Linq (from Microsoft) as a good example that it is possible to offer such a bandwidth efficient framework for data access to the developer. Even with Linq it is still up to the developer to limit the request to the columns used; the compiler has not yet capabilities to determine which columns are used and thus limit the request to these columns. Making an application 'cloud ready' might require some effort, making that application 'cloud database ready' certainly does!