Blog Post

Survey: NoSQL adoption driven by schema hate

Stay on Top of Enterprise Technology Trends

Get updates impacting your industry from our GigaOm Research Community
Join the Community!

Almost half of 1,300 database pros surveyed have solid plans to move some work to NoSQL databases in the first half of this year, according to new research. In companies with more than 250 developers, 70 percent have funded NoSQL projects, according to a survey conducted by Couchbase, which as a NoSQL database company certainly has a dog in this fight.

It’s not surprising that respondents had a NoSQL bent given that Couchbase recruited them from Twitter (using the NoSQL hashtag), InfoQ as well as the company’s own database. Still, some of the results were interesting.

NoSQL (or not only SQL) databases, which do not rely on the SQL query language commonly used in relational databases from Oracle (s orcl),  Microsoft (s msft), and IBM (s ibm), got their start in webscale companies like Google and Yahoo that needed their ability to scale out across multiple servers. MongoDB, Cassandra are other NoSQL databases.

Of those planning to make the transition, the biggest motivation was disdain for the inflexible schemas that are part-and-parcel of SQL databases, according to the survey. Nearly half (49 percent) of those surveyed said schemas drove them to NoSQL. The second biggest factor, cited by 35 percent, was the inability of relational databases to handle scale-out data.

One of NoSQL’s biggest draws is that users don’t have to scope out their data fields — name, phone number, state — in advance and then be held captive to those schemas.

It was striking that the language cited by most of NoSQL-loving respondents was Java, followed closely by PHP, then C#.  “That could be surprising that the favorite was not Ruby or the bleeding-edge funky languages,” said James Phillips, Couchbase co-founder and SVP of products.

NoSQL is definitely gaining traction but the pure-play NoSQL players will see increasing competition from the RDBMS world as well. Virtually all the RDBMS players including Oracle are coming out with their own NoSQL plays.

3 Responses to “Survey: NoSQL adoption driven by schema hate”

  1. NoSQL datastores are legitimately attractive to developers who need schema flexibility. As one who works for a RDBMS vendor, I’ve spoken with several developers who prefer the schemaless model because they feel it gives them more agility. If that’s your driving priority, pick the NoSQL product that best suits your data (documents, social graphs, etc.) and have at it.

    Alternatively, if your driving priorities are throughput and scale, NoSQL is not the only game in town. A rapidly-expanding community of NewSQL solutions satisfy those needs in spades. VoltDB, for example, can easily scale out on commodity servers and support millions of write operations per second at single-millisecond latencies. What’s more, it delivers those benefits without sacrificing ACID guarantees and supports a data language (SQL) that’s stood the test of time.

    Rational guidance says to choose the right tool for the job. That means balancing the needs of agile, iterative development with what’s required to operate high-scaling production systems.

  2. David Colbourn

    NoSQL is another flexible tool in a series of attempts to move the system and application DBA functions as well as data architecture and design under the programming staff. If the optimization goal is to increase speed of development then the loosening of standards it is a type of right move in that direction. If the optimization goal is interoperability and reuse (MDM ESB or SOA) then it is not. I suspect looking at the objectives of the architectural area it is being rolled out in may give you more then a 49% overlap.

    • James Phillips

      Very interesting observation. Though I might suggest that if what you are trying to do is expose a set of services (MDM ESB or SOA) then doing that from the database itself *may* not be the right approach. Because the database tier may need to scale to support many different users (direct application access, backing a SOA service, etc.) it may be best to have a “service server” that abstracts the data while enforcing security and other policies. That way, the data model on the back end can still adapt to the needs of the various users without “breaking” the services that depend on the data.