Knowledge Hub

NoSQL Data Modelling refers to the practice of designing data structures for non-relational databases such as document stores, key-value stores, wide-column databases, and graph databases. Unlike relational modelling, which is driven by normalization theory and functional dependencies, NoSQL modelling is driven primarily by application access patterns and workload requirements. The goal is not theoretical purity but scalable, high-performance data access.

The primary objective of NoSQL data modelling is to support flexible or schema-less storage, distributed scale-out architectures, and fast, query-driven design. Instead of decomposing data into highly normalized tables, NoSQL models are often intentionally denormalized or embedded to minimize joins and reduce cross-node communication in distributed environments. Data is structured according to how it will be read and written, not according to relational dependency rules.

Document databases store data as JSON-like documents that can contain nested fields, arrays, and variable structures. Instead of organizing information into rows and columns, they treat each document as a self-contained representation of a business object. The goal is to provide flexible schema design and rapid development by allowing complete entities to be stored and retrieved in a single record.

In a document database, each document typically represents one business object. In a loan approval system, for example, a single document may represent an entire loan application. Customer details, loan officer information, approval status, and repayment history can all be embedded within that same structure. Because the schema is flexible, new fields can be added without requiring costly table migrations or rigid schema alterations. This makes document databases particularly attractive in fast-moving development environments.

Key–Value databases represent the simplest form of non-relational data storage. They store data as a pair consisting of a unique key and its associated value. The key serves as an identifier, while the value contains the data itself. This model eliminates structural complexity and focuses entirely on fast retrieval by key.

The primary goal of key–value databases is to deliver ultra-fast lookups with minimal overhead. They are designed for workloads where the access pattern is simple and predictable, such as caching, session management, token storage, or high-volume read/write operations. Instead of supporting complex queries, these systems optimize for speed and scalability.

In a key–value database, each record is accessed directly through its key. The value associated with that key can be a simple string, a JSON object, or even a binary blob. There is no concept of joins, relational constraints, or query-based filtering beyond key lookup. This makes the model extremely efficient for operations such as “fetch loan details by LoanID.”

Wide-Column databases, often referred to as column-family databases, organize data into rows and dynamic columns grouped into column families. Unlike traditional relational tables where every row follows a fixed schema, wide-column systems allow each row to contain a flexible and potentially sparse set of columns. They are optimized for distributed storage and partitioned queries across very large datasets.

The primary goal of wide-column databases is to enable high write throughput and scalable query performance over massive volumes of data. They are particularly well suited for time-series, event-driven, and high-velocity workloads where large amounts of data must be written and retrieved efficiently across distributed clusters.

In this model, data is partitioned by a primary key, for example, CustomerID or LoanID. All related data for that key is stored together within a partition. Within each partition, rows may contain flexible columns that vary between records. The schema is shaped primarily by access patterns. Instead of normalizing entities into separate tables, designers structure data to answer specific queries efficiently.

Graph databases store data as nodes and edges, optimized specifically for representing and querying connected information. Nodes represent entities, while edges represent relationships between those entities. Unlike relational systems that organize data into tables and connect them through joins, graph databases treat relationships as first-class citizens, enabling direct traversal across connections.

The primary goal of graph databases is to uncover insights from relationships and networks. They are particularly effective in scenarios such as fraud detection, influence analysis, recommendation systems, and complex workflow analysis, areas where relational joins become expensive and difficult to manage at scale. When the question being asked is fundamentally about how things are connected, graph databases often provide a more natural solution.

In a loan approval context, nodes might represent entities such as Customer, Loan, LoanOfficer, and Branch. Edges define how these entities are connected. For example, a Customer applies for a Loan, an Officer approves a Loan, and a Loan is issued at a Branch. Because relationships are stored explicitly rather than inferred through joins, queries can traverse the network efficiently.

NEON-Inspired Architecture refers to a modern architectural approach that separates storage from compute, allowing systems to scale more efficiently and flexibly. The idea is inspired by cloud-native database designs where data storage and processing power are decoupled instead of tightly integrated.

In traditional database systems, storage and compute are bundled together. If you need more processing power, you often have to scale the entire system, including storage, even if storage capacity is sufficient. This creates inefficiencies in cost and scalability.

In a NEON-inspired approach, storage and compute operate independently. Storage is centralized and durable, while compute instances can scale up or down based on workload demand. This architecture supports elasticity, better resource utilization, and faster provisioning of environments.

One of the well-known implementations of this concept is Neon, which applies serverless principles to PostgreSQL by separating compute nodes from storage layers. While the term “NEON-inspired” may not refer exclusively to that company, it reflects the broader architectural pattern of disaggregation and cloud-native database design.

On-Premises and Cloud both compete but at backend both operate the same way.

Since years and years Cloud is trying to make a mark but some or the other reason it couldn’t. Now things have changed, in recent era, Cloud has become arguably the biggest buzzword after the Covid-19 pandemic in 2019/20, as organizations had to enable Cloud services for their employees to support their businesses.

Let’s try to understand the core difference, to use IT solutions there are always two options either to have all the software(s) on On-Premises or on Cloud.

On-Premises: When an organization buys servers and infrastructure, and places those inside their own location or building under their own control, managed by their own internal teams, it is called On-Premises.

Cloud: Now when someone else places servers and infrastructure in their location or in their building and manages it for customer where customer accesses those servers and infrastructure via internet, it is called Cloud.

In IaaS, online compute power and storage is provided to customers in the shape of Virtual Machines (VS). Customers must bring their own software, tools and IT Solutions and then manage the environment, from installing/ upgrading software, HA, DR, compute power, storage standard etc., on its own. Cloud Service provider charges based on compute and storage usage.

Cloud example segregating IaaS:

If you only expect Me (Service Provider) to buy laptops (Infrastructure or Servers) with ONLY having Operating System of your choice and give you access and all rest of the activities like to install your special software(s) on it, install security software(s), enable software encryption, replaces normal hard disk with encryption disk, install all MS Office software(s) on it for daily activities, install database on it, configure Disaster Recovery and High Availability Strategy like taking backup on an external disk and keep moving data on periodic basic on second laptop so just in case if first laptop crashes, work can be continued on second laptop, periodic upgrading all the software(s) on both laptops etc. etc. etc. all will be take care by yourself is IaaS.

We have discussed differences between On-Premises and Cloud then IaaS where only Hardware is rented by Cloud providers. Next stage of this paradigm change is to rent Containers at a small scale, to save cost and for better management of resources. CaaS (Container as A Service) is one level lower than IaaS to rent resources on Cloud.

As the name says itself, CaaS (Container as A Service) is about deploying code in a container and deploying that container in Cloud. This saves us to manage hardware on our own in Cloud i.e., IaaS, so we can deploy our containers and underneath it, the hardware will be managed by Cloud providers. Most of the Cloud providers are offering CaaS.

You are using Agile Methodology then you need CI/ CD (explained separately). In Agile, most of the time we have multiple teams working in silos on different modules on the same project and can be on the same deliverable. CaaS can be very helpful in this methodology where different teams are able to develop and deploy their code set any time using CI/ CD pipelines.

As we move from IaaS to CaaS to PaaS, it becomes confusing. In IaaS and CaaS, we established that Infrastructure/ Servers and Storage is provided by Cloud providers and rest of all the activities are managed by customer team, itself. Now, let’s try to understand PaaS where all software(s) are made available for customers by the Cloud provider. Software(s) are already installed and ready to use. Customers don’t have to manage any compute or storage; everything is managed automatically by Cloud provider.

If you expect Me (Service Provider) to buy laptops (Infrastructure or Servers) with all the possible software(s) pre-installed and made those available to you via Internet, ready to be used in few clicks. Along with software(s) all rest of the activities like to install security software(s), enable software(s) encryption, replaces normal hard disk with encryption disk, install all MS Office software(s) on it for daily activities, install database on it, configure Disaster Recovery and High Availability Strategy like taking backup on an external disk and keep moving data on periodic basic on second laptop so just in case if first laptop crashes, work can be continued on second laptop, periodic upgrading all the software(s) on both laptops etc., all will be taken care by Me (Cloud Provider) is PaaS.