NimbusDB has many distinctive features underpinning its unique architecture. Chief among them is the manner by which multiple nodes cooperate to manage the state of the database. Unlike traditional database architecture where there is a data file and accompanying transaction log files NimbusDB manages all data in much the same way peer-to-peer systems such as BitTorrent do. That is to say that the data, indexes, and transactional state exist across many nodes, delivered on demand to those nodes that need that information from those nodes containing the requested data. Data is only made persistent to stable storage by nodes participating in the system for the purpose of permanent storage.

This departure from traditional RDBMS architecture provided the freedom to rethink transactional guarantees and durability in a dynamic distributed system. At the SQL query processing layers of NimbusDB you'll find a system that can optimize queries for in-memory, single-node execution or when data size or query complexity exceeds a single node's capacity the query can be optimized to collaborate with other nodes.

The single most common bottleneck in all databases systems is durability, the overhead when storing data to some form of stable storage such as a disk. In NimbusDB durability is achieved though the use of one or more storage strategies built to solve specific storage issues. Some storage implementations shard data across many nodes aggregating bandwidth where others are optimized for long term backup for archival and auditing. All elements in a system collaborate to ensure the durability and availability of data.

NimbusDB implements the majority of the SQL99 standard. Existing standards-compliant databases will port and run with minimal, if any, modification. NimbusDB isn't simply a new storage engine for MySQL or other existing database, it is a new SQL engine written to take full advantage of distributed, cooperative nodes. The result is that databases designers will not need to compromise on schema design by de-normalizing tables, removing joins, or carefully optimizing object-to-relational tools to get the performance their application needs. These trade-offs may be required in other systems, but not with NimbusDB.

NimbusDB is clustered by default. The cluster adjusts when nodes enter or leave, it adjusts as new resources become available or are removed all without the need for downtime. Nodes performing transactions maintain no persistent state, if the one you happen to be connected to a node that fails a simple reconnect to any other available node allows you to continue processing. Data is spread out across transaction and storage nodes and it always available. When network partitions occur NimbusDB continues offering services via the most available and healthy segment while the other segments provide a consistent read-only snapshot while awaiting reconnection at which point they will synchronize with their counterparts. Clients can simply reconnect to the active partition of the cluster to continue processing updates.

Scale transaction throughput by adding a new transactional node. Scale data volumes or lower latency by adding storage nodes that share, cache and record all changes in the system. Scaling NimbusDB is easy because it was designed from the ground up to be a multinode distributed data management system.

An even more critical feature in today's cost conscience and resource constrained IT landscapes is the ability to grow, shrink, allocate, reassign, and provision database service resources according to need, or policy. Just as virtualized systems allow more efficient use, provisioning, monitoring, and repurposing of hardware resources NimbusDB enables efficient multitenancy and automatic policy-based provisioning.

NimbusDB is simple, it requires minimal configuration and almost no oversight in production. Administrators configure policy files, allocate systems resources in the cloud or from local resources and then step back while NimbusDB manages those resources automatically adjusting as required. Monitoring consoles provide a detailed operational view of the NimbusDB cluster as a whole showing how resources are allocated, operational characteristics, and any system alerts.

A developer simply writes applications using standard SQL connecting over the network using one of many standards-based language or environment-specific drivers such as JDBC, ODBC, etc. To a developer NimbusDB is almost indistinguishable from a traditional client/server RDBMS. A developer can work locally on their development system or collaborate with other developers across many systems in a seamless manner.