You are here

Blackbirds Reading & Watching

Error message

Note: This blog was published over a year ago. Content may be out of date.

Now that our 2.0 blackbirds release is out we're hearing a lot of great questions about the core technology and which problems we're addressing. Rather than keep answering these separately here's a clip show. Between the material on this blog, some talks & articles and a few comments to fill in the gaps I hope to give you a good sense of what we've done with this release and where we're headed.

Let's start with the basics. On October 16 we did a live webcast to talk about experiences that led us to the 2.0 release. It's a pretty good overview. It also features our friend Cameron Weeks, CEO of Fathom Voice talking about why they chose NuoDB and what problems they need to solve (hint: high-availability and low-latency in a multi-region AWS deployment). You can find the launch slides online or you can watch the geo-distributed automation demo.

A week later I was down in NYC for a meet-up. Since there's been a lot of interest in the automation features we're starting to roll into the product, I made it something of an interactive demo. Go checkout the meetup video or the slides online. The point? Usability is something you bake into the lowest layers of a distributed system, not something you get by bolting on a pretty UI. Yes, it's taking us a little while to build out all the right features, but now that they're maturing we're able to do some pretty cool stuff.

What I didn't really focus on in that talk is what's going on under the covers of a NuoDB database. For that, check out the new white paper we just posted. It goes into the rationale behind our design, the kinds of problems you can solve with our architecture and hints at some future directions. Oh, and yeah, if you want to know about "atoms", "chairmen" and MVCC that's there too.

One of the common questions we hear is how we're different than NoSQL systems, or traditional RDBMSs. I think the simple answer to the former is that we're transactional, so we provide a clear consistency model, and we support SQL. We actually support several standard isolation models so you can choose which consistency model you need. By comparison to traditional RDBMSs I think the simplicity of our management model, on-demand scaling and the ability to deploy multi-data-center without sharding or replication delays is pretty exciting and different.

Along these lines, our CEO Barry Morris started a set of articles capturing his thoughts on what we're trying to do and how that's a best of both worlds approach. I also recently weighed-in on why transactions are still the way to go. Will we be thinking about non-SQL interfaces to distributed data for future releases? Yes, of course. With our 2.0 release, however, we think we're making a pretty strong case for why SQL is critical, powerful and able to tackle next-generation use-cases.

Finally, there's been a decent thread lately on consistency and failure models, and where NuoDB lives in that spectrum. I'm not going into all the details here (we'll save that for a series of articles coming soon). To get you thinking in the right vein, however, I started a new blog and captured some of my general thoughts about consistency & failure in distributed systems. NuoDB is an ACID database. What we'll be demoing over the coming months is how the features in 2.0 let you define service-level requirements, guaranetees in the face of failure and prefered isolation levels.

So that's the quick round-up. Hopefully the links keep you entertained for a while, and maybe even get you interested in trying out our latest release. Give it a shot and let us know what you think!

Add new comment