NoSQL Design Principles

NoSQL Design Principles Definition

NoSQL databases support non-relational data models, which provide for a range of NoSQL design principles for non-relational data. Non-relational data models are flexible, and schema management is often delegated to application developers, who are relatively free to adapt data models independently.

Diagram comparing SQL (relational and analytical) versus NoSQL (key-value, document, graph, wide column).

NoSQL Design Principles FAQs

What are NoSQL Design Principles?

NoSQL databases require a different design approach than that used with traditional relational database management systems (RDBMS). The rise in popularity of NoSQL databases paralleled the adoption of agile and DevOps practices. Unlike RDBMSs, NoSQL databases encourage ‘application-first’ or API-first development patterns. Before considering the data models and entities, developers first consider queries that support the functionality specific to an application. This developer-friendly architecture paved the path to the success of the first generation of NoSQL databases.

In contrast, relational databases impose fairly rigid, schema-based structures to data models; tables consisting of columns and rows. Each table typically defines an entity. Each row in a table holds one entry, and each column contains a specific piece of information for that record. The relationships among tables are clearly defined and usually enforced by schemas and database rules.

In the world of relational databases, schemas are usually managed by a centralized team of database administrators, who ensure that data models and data types are consistent across multiple applications. This situation can often introduce friction between administrators and development teams. This friction often translates into very long, non-agile application development lifecycles. Such highly structured data requires normalization to reduce redundancy and improve reliability. The data model is based on the entity being represented; query patterns are a secondary consideration.

NoSQL inverts this approach. Non-relational data models are flexible, and schema management is often delegated to application developers, who are relatively free to adapt data models independently. Such a decentralized approach accelerates development cycles and provides a more agile approach to addressing user requirements. Application developers can easily add properties and attributes, and the changes can be applied to existing data sets. This enables developers to add new features more quickly than if a schema migration were required.

The first step to understanding NoSQL database design principles is to understand the basic flavors of NoSQL available today. Besides these basic types, NoSQL hybrid databases can combine some of these types.

  • Document Store: Data and metadata are stored hierarchically in JSON-based documents inside the database.
  • Key Value Store: The simplest of the NoSQL databases, data is represented as a collection of key-value pairs.
  • Wide-Column Store: Related data is stored as a set of nested-key/value pairs within a single column.
  • Graph Store: Data is stored in a graph structure as node, edge, and data properties.

nosql design principles mascot

Learn about the 7 design principles for high performance low-latency NoSQL.


Read Paper

What Are Advantages of a Wide-column Database?

Benefits of a wide-column NoSQL database include speed of querying, scalability, and a flexible data model.

Masterclass: Data Modeling for NoSQL Databases

Looking for extensive training on about data modeling for NoSQL Databases? Our experts offer a 3-hour masterclass that assists practitioners wanting to migrate from SQL to NoSQL or advance their understanding of NoSQL data modeling. This free, self-paced class covers techniques and best practices on NoSQL data modeling that will help you steer clear of mistakes that could inconvenience any engineering team.

You can access the complete course here.

What Type of NoSQL Database is Best?

The right type of database depends on your application’s requirements. The first NoSQL design guideline is to know how your application will access the data. Occam’s Razor says the simplest solution is almost always the best solution. Or, put another way, do the simplest thing that works. If a key-value store is all you need, don’t use a more complex solution.

If you’re primarily storing unstructured data, or data with inconsistent structures, where queries are typically against metadata, consider a document database. For data with interconnected relationships, where understanding and managing those relationships is a primary concern, use a graph database.

Other than those special cases, when you find yourself considering a relational database management system (RDBMS) but need high availability and distributed architecture more than strong consistency, the wide-column database is a great choice.

What Are NoSQL BASE Design Principles vs ACID?

Database administrators (DBAs) of RDBMS systems are familiar with the ACID acronym, which stands for: Atomic, Consistent, Isolated, Durable. By contrast, BASE stands for Basic Availability, Soft-state, Eventual consistency. One of the important NoSQL BASE design principles to consider is that you must understand the level of consistency required by your application. For example if you are reporting moving averages in virus test samples, you don’t need high consistency. Missing the last two test results won’t change your average. On the other hand, a financial application probably needs strong consistency. You could still use NoSQL, but you would want to select a stronger consistency level.

How Do You Design NoSQL Schema?

NoSQL data modeling is an application-centric approach that is more concerned with how the application will query the data than the relationships within the data. NoSQL database design principles emphasize the flexibility of the data, as opposed to a rigid relational schema.

Duplication and denormalization of data are acceptable under NoSQL design principles. It’s ok to store a data element again because NoSQL databases don’t join across tables.

NoSQL database schema design encourages aggregating hierarchical data instead of splitting out elements that will later be joined and retrieved together. One-to-many relationships are modeled in NoSQL as nested elements. If elements of that hierarchy tend to change independently, the application can better handle the join by loading related data elements via links. Many-to-many relationships are handled by links.

What are NoSQL Partition and Row Key Design Principles?

Partition keys can help with sharding data across nodes for better distribution or organizing data by customer, by date, etc. Composite row keys that include more than one key field are especially useful for quicker queries when the NoSQL database supports ordered keys. Composite row keys function as a clustered composite index in a relational database.

When an application needs an additional index against a table, a new table with a composite row key with the sole function of pointing to the table being “indexed” is a common technique.

Although NoSQL schemas are flexible, the partition and row keys should be based on data or metadata that is required.

What are Best Practices for How Many Nodes to Use?

Within ScyllaDB, the minimum Replication Factor to achieve high availability is 3. If one node fails, and a new node must be created, the data from two nodes must be available to make sure the new node is created with consistent data. For higher read performance, more nodes can be used, and none of the nodes would need to have all of the data. Locating those nodes across geographical areas can also protect against regional outages.

How To Choose NoSQL Consistency Level?

One of the NoSQL design guidelines is to select the appropriate consistency level. When data is written, how many nodes must have the data written before the write process is considered successful? That will depend on the needs of the application, so ScyllaDB offers a Tunable Consistency with options such as:

  • Consistency Level One: Once the data is written to a single node, the write is successful.
  • Quorum Consistency: Once the data is written to a majority of replicas, the write is successful.
  • Consistency Level All: The data must be written to all replicas to be considered successful.

Can a Wide-column Database Support Different Columns on Some Rows?

Wide-column databases don’t have a defined table schema, which leaves them flexible to have certain columns only apply to certain records.

How is NoSQL Ecommerce Design Different?

NoSQL is frequently used for Ecommerce sites because of its query speed, flexibility, and availability. NoSQL ecommerce design is a little different than RDBMS design for an ecommerce site. An ecommerce site typically sells products, and those products have properties or attributes that describe them. A shopper looking for a shirt wants to filter by style, color, size, and possibly brand. A shopper looking for a hard drive wants to filter by size, interface, and drive type. A relational database design to make all product attributes searchable becomes very complex, and complex queries are slow queries. NoSQL ecommerce design is simplified, because not every row (product) needs the same columns (attributes).

Does ScyllaDB Adhere to Modern NoSQL Design Principles?

ScyllaDB, The World’s fastest NoSQL Database fully supports NoSQL design principles via full compliance with Cassandra Query Language (CQL).

Trending NoSQL Resources

ScyllaDB University Mascot

ScyllaDB University

Get started on your path to becoming a ScyllaDB expert.