You are here

Welcome to the NuoDB Blog

  • We get a lot of questions about the caching part of our architecture, and whether NuoDB is an “ in-memory ” database. After all, there are many different types of caches, and it’s a key element of how a system performs. This is the first in a few entries that will explain what caching really means in NuoDB, how it’s different from other systems and what that means to you as a user.

    What the cache is

    Recall that a NuoDB database is

  • In a previous entry I talked about how installing the software is a provisioning step that gets you ready to work with NuoDB. Great, but what you probably want to do is actually run a database.

    If you login to the web console (you should .. it’s cool) you’ll see a big “Start Database” button. Click this, walk through a few steps and you’ve got a database running that is expandable, secure and ready for use. If you want to understand a little more

  • Greetings stalwart technical nuonians! I am back with a follow on to my previous MVCC post. Part 1 gave a high-level abstract overview of the problem that MVCC was meant to solve, and a basic sketch of how a database would use MVCC to maximize concurrency. Now, in part 2 I hope to make these concepts more concrete by giving specific examples.

    Example 1: Reads and Updates

    Consider a table with at least 3 live rows in it. Assume each row has some ID value. Given that, let’s examine the case where

  • Greetings, technically-minded nuonians! I am Trek Palmer and I am one of the engineers here at nuodb. I spend most of my time implementing and debugging the atom layer of nuodb. For the last year I’ve been living and breathing distributed transactional consistency. Recently, I’ve had the opportunity to engage directly with customers and users of nuodb and one of the questions that routinely arises is how we maintain consistency in the face of ridiculous numbers of updates on multiple nodes simultaneously. The answer is, in fact, that we have an implementation of Multi-Version

  • NuoDB is a multi-tenant product. That’s a cloud buzzword, but essentially it means that with a single install of the software you can run any number of distinct databases serving distinct clients. Each database maintains its own physically separate archives and runs with its own set of security credentials. Neat, huh?

    To make this model usable and useful we have a management tier that supports a simple (and scriptable) notion of administration. When you install the

  • We use JIRA for issue-tracking. It’s a great product that uses a relational database back-end.

    Our goal is to use NuoDB in-house as much as possible, and by getting JIRA running against NuoDB we could confirm that NuoDB is production-ready and capable of driving complex enterprise applications.

    What are the benefits of running JIRA on NuoDB?

  • Welcome to the new engineering blog at NuoDB!

    Now that we’re a GA product, the engineering team wants to share some of the cool things you can do with the product today and some of the directions that the product is taking in the future. We’re excited about what we’ve built. We want you to be too.

    If you haven’t found them already, we also have a corporate blog and a

  • Pluggable databases give developers and administrators the ability to create a database container and provision multiple databases within that single container. This is also known as multi-tenancy.

    Sounds AMAZING doesn’t it…

    The cloud environment

  • I recently saw a piece by Matt Aslett, Principal Analyst at 451 Research on multi-model databases. (Click here to read the full article.)

    At NuoDB we have a lot of respect for Matt and his viewpoints.

    He mentions us in the blog (thank you, Matt) but I’d like to expand on his comments here.

    The NuoDB SQL engine is a personality for the atom layer. We are actively working on personalities other than the default SQL personality. That’s a