NosDB: Performance and Scalability Benchmarks

This document describes the performance results of NosDB in a distributed environment. Please note that these tests were conducted in a QA environment. You are likely to get better performance in your production environment than reported here.

Key Terms

To understand the benchmark results here are a few key terms to guide you:

  • Shards in a cluster: A NosDB cluster is divided into shards. A cluster can practically host an unlimited number of shards and is composed of one or more server machines (Nodes) using NosDB.
  • Primary Nodes: A single designated node in any shard is called the Primary Node. Each shard has only one primary and it handles all the read and write operations for associated shards.
  • Secondary Nodes: In a shard, all nodes, other than the Primary Node, are called Secondary Nodes. The Secondary Nodes replicate all data from the Primary to ensure high availability.
  • Scalability: Unlike a relational database, data is distributed across multiple shards hence the transaction load is also distributed. Shards can be added or removed any time so your database scales on an "as needed" basis. In addition to scaling by adding shards, individual nodes can also be added or removed, thus providing multi-dimensional scaling capability. To boost performance even more, you can redirect read operations to your Secondary Nodes. This offloads volume from the Primary Node. For more information, please check the conceptual guide.
  • Availability: Use of Primary and Secondary Nodes provides high availability. If a Primary Node goes down, a secondary node can take its place (through election) and becomes the new Primary. The Secondary Node starts serving clients without any visible interruption, and with zero data loss, to your client applications.

Testing Configuration and Results

Operating System: Windows 2012 R2 Server
Architecture: X64
Number of processors: Octa Core Processor
Memory: 28GB in each server
NosDB version: 1.3 SP2
Network speed: Two 1-Gbit NICs
Client Configuration: NET Clients accessing database cluster over LAN. Number of clients increased until max load achieved for the given database cluster size.
Data size: JSON object + 1KB of data

Each shard in our benchmark test has one Primary Node and one Secondary Node. The number of clients and client machines are increased until the maximum load is achieved for the NosDB cluster size. Our scalability test starts from a cluster consisting of a single shard. To measure the scalability of NosDB, new shards are added and the tests are rerun. The following diagrams report the benchmark test results.

Document Writes/Reads

As you can see, throughput of reads and writes increases with the number of shards, showing that NosDB is linearly scalable. given the fact that the more shards we add to the cluster the more the data throughput increases.

Read Writes nosql


For this benchmark, three types of queries (containing the WHERE clause) were run to fetch data:

  • Value lies between a specified range
  • Value is greater than a specified value
  • Value is lesser than a specified value

The results are shown below.

NoSQL Query

Query performance improves as we increase the number of shards in the cluster, showing linear scalability for queries. In a practical sense, you can add shards without limit and increase your data throughput linearly with every addition. This eliminates even the possibility that your database tier will become a data through-put bottleneck.