NewSQL thoughts
I plan to write about several NewSQL vendors soon, but first here’s an overview post. Like “NoSQL”, the term “NewSQL” has an identifiable, recent coiner — Matt Aslett in 2011 — yet a somewhat fluid meaning. Wikipedia suggests that NewSQL comprises three things:
- OLTP- (OnLine Transaction Processing)/short-request-oriented SQL DBMS that are newer than MySQL.
- Innovative MySQL engines.
- Transparent sharding systems that can be used with, for example, MySQL.
I think that’s a pretty good working definition, and will likely remain one unless or until:
- SQL-oriented and NoSQL-oriented systems blur indistinguishably.
- MySQL (or PostgreSQL) laps the field with innovative features.
To date, NewSQL adoption has been limited.
- NewSQL vendors I’ve written about in the past include Akiban, Tokutek, CodeFutures (dbShards), Clustrix, Schooner (Membrain), VoltDB, ScaleBase, and ScaleDB, with GenieDB and NuoDB coming soon.
- But I’m dubious whether, even taken together, all those vendors have as many customers or production references as any of 10gen, Couchbase, DataStax, or Cloudant.*
That said, the problem may lie more on the supply side than in demand. Developing a competitive SQL DBMS turns out to be harder than developing something in the NoSQL state of the art.
*Revenue might be a different matter.
The main reasons for NewSQL adoption tend to fall in the areas of performance, scaling, manageability and cost. But while they all support SQL, some NewSQL DBMS have differentiated programming models even so.
- Akiban wants you to consider mixing access — to the same data in the same data structures — among SQL, JSON and, say, Hibernate.
- Tokutek turns a performance argument into a functionality one. In particular, Tokutek claims that TokuDB does a much better job than alternatives of making it practical for you to update indexes at OLTP speeds. Hence, it claims to do a much better job than alternatives of making it practical for you to write and execute queries that only make sense when indexes (or other analytic performance boosts) are in place.
- As a trade-off for blazing in-memory performance, VoltDB is hampered by an innovative and restrictive programming model.
Also, the MySQL add-ons and lookalikes vary in the (in)completeness of their MySQL emulation or support.
The most common performance/scaling NewSQL claims are simply “We scale, giving you the power of multiple servers, with sufficiently little downside in the way of tradeoffs.” That story is central to Clustrix, VoltDB, ScaleDB, NuoDB, and to anybody active in transparent sharding. Other performance/scaling claims include but are not limited to:
- Optimized for RAM (VoltDB).
- Optimized for flash (Schooner/Membrain).
- Writes indexes quickly (TokuDB).
- Fast joins (Akiban).
Management claims include (from multiple NewSQL vendors in each case):
- Little added management pain, but you get scale-out!
- Little added management pain, but you get active-active/multi-master wide-area replication!
- Online schema change and other uninterrupted operation features.
- Not as cumbersome as Oracle.
And that’s about as much as I’m ready to generalize about the NewSQL sector. Posts about particular product and companies are on the way.
Comments
19 Responses to “NewSQL thoughts”
Leave a Reply
Thanks for the insights. Reference to “NoSQL” in the last sentence of the first paragraph should be “NewSQL,” however.
Thanks! Fixed (in two places).
FoundationDB? ACID, OLTP, Key-Value. Calling themselves NoSQL but they seem to be NewSQL.
http://foundationdb.com/
Well, FoundationDB has never reached out to me, and I don’t know much about them. But based on their website, they don’t seem to support SQL or a SQL-like DML.
The point of SQL vs. NoSQL is that you can normalize (even slightly) and do joins.
[…] is one of the newer and smaller NewSQL companies. GenieDB’s story is focused on wide-area replication and uptime, coupled to claims […]
Curt, SQL-oriented and NoSQL-oriented systems are starting to blur. There’s a movement towards databases that natively store data in a hierarchy (aka “nested data”) allowing for a combination of document like structures with SQL. Google Dremel, Apache Drill, Google F1 and (our own) Akiban are some examples. All reconsider the basic premise that a SQL capable database is required to have the concept of tables in its physical implementation.
[…] has an interesting NewSQL story. NuoDB’s core design goals seem to […]
[…] that I’ve addressed some new NewSQL entrants, namely NuoDB and GenieDB, it’s time to circle back to some more established ones. […]
[…] of convergence. As a Big Data enthusiast I love this energy. Curt Monash has started his year blogging about NewSQL. I have blogged about a couple of NewSQL vendors, NimbusDB (NuoDB) and GenieDB, in the past […]
[…] of convergence. As a Big Data enthusiast I love this energy. Curt Monash has started his year blogging about NewSQL. I have blogged about a couple of NewSQL vendors, NimbusDB (NuoDB) and GenieDB, in the past and I […]
[…] guru Curt Monash includes in the NewSQL club suppliers such as (in no particular order) Akiban, GenieDB, Tokutek, CodeFutures, Clustrix, […]
[…] further say that NoSQL is cheaper, scales better, is cooler or whatever, but given the range of NewSQL alternatives, those claims are often […]
Is Schooner dead? I just get 404 errors now on their website…
Schooner was taken out by SanDisk. Unconfirmed rumor has it that the product is not being continued in its current form. Jerry Rudisin hasn’t gotten around yet to giving me the real scoop. 🙂
[…] Artikkelissa d Jaa:TwitterFacebookGoogle +1TulostaTykkää tästä:Tykkää Lataa… Bookmark the permalink. Jätä kommentti […]
[…] most other NewSQL and NoSQL DBMS, DeepDB is append-only, and hence could be said to “stream” data to […]
Great post Curt!!. Will appreciate your views on sqrrl. Seem to have some very interesting features for enterprise and works on Hadoop.
I’d say that NewSQL is still maturing. They had to make trade-offs just like the first NoSQL databases did. It will be interesting to see what happens when they no longer have to make these trade-offs.
[…] in NoSQL/NewSQL short-request processing performance claims seem particularly confused. Reasons include but are not […]