(I am the CEO of Zoho) Let me provide some context on this. What we are doing is to separate the two layers in a database that have traditionally been so welded together that you don't even think of them as two layers: the SQL processing "logical" layer and the storage "physical" layer.
Our real technology here is a multi-dialect SQL processing engine, which can handle a wide variety of SQL dialects with ease (ANSI, Oracle, SQL Server, DB2, MySQL, Postgres being the major variants). At AdventNet, we have offered a product called SwisSQL to companies, for SQL migration, conversion etc. for a while (4+ years now). We couple that technology with physical storage or other APIs underneath.
Once you decouple the two layers, a lot of possibilities open up. The "slow, risky, inefficient" part is really a function of how efficient the middleware is in processing a variety of SQL dialects and translating it to what the physical layer needs.
SQL is the mainstay of business information processing. We are using the standard everyone loves (or loves to hate in some cases!) and bring it to the cloud computing era. Our goal is to preserve compatibility for existing applications - hence our JDBC driver etc. - while drastically lowering the cost. Today's announcement is only the first step on a long road ahead.
To add a hacker news dimension, I have long been fascinated with relational data modeling. I have always believed that welding together storage with relational models was a disservice to Codd's brilliant work. There are a lot more ways in which relational modeling power can be exploited without tying it so closely to a specific storage context.
Our real technology here is a multi-dialect SQL processing engine, which can handle a wide variety of SQL dialects with ease (ANSI, Oracle, SQL Server, DB2, MySQL, Postgres being the major variants). At AdventNet, we have offered a product called SwisSQL to companies, for SQL migration, conversion etc. for a while (4+ years now). We couple that technology with physical storage or other APIs underneath.
Once you decouple the two layers, a lot of possibilities open up. The "slow, risky, inefficient" part is really a function of how efficient the middleware is in processing a variety of SQL dialects and translating it to what the physical layer needs.
SQL is the mainstay of business information processing. We are using the standard everyone loves (or loves to hate in some cases!) and bring it to the cloud computing era. Our goal is to preserve compatibility for existing applications - hence our JDBC driver etc. - while drastically lowering the cost. Today's announcement is only the first step on a long road ahead.
To add a hacker news dimension, I have long been fascinated with relational data modeling. I have always believed that welding together storage with relational models was a disservice to Codd's brilliant work. There are a lot more ways in which relational modeling power can be exploited without tying it so closely to a specific storage context.