When designing a modern application, you will almost always need a database not just to store data, but also to efficiently transform and retrieve data when required. From the time of inception, database architecture and database management systems have evolved from traditional, rigid systems to more modern, horizontally scalable systems, more suited to today’s digitized universe.
Table of contents
The term "database architecture" refers to the structural design and methodology of a database system, which forms the core of a database management system (DBMS). This architecture dictates how data is stored, organized, and retrieved, playing a crucial role in effective and efficient data management.
The first step while designing any DBMS architecture is to decide on the type of database to use. The database could be centralized or decentralized.
A centralized database is stored and managed at a single location, typically on a server or a computer. Users access the database through networks such as Local Area Network (LAN) or Wide Area Network (WAN).
In contrast, a decentralized or distributed database consists of data stored across multiple physical locations (nodes), typically managed by different systems or servers. While each node or site operates independently, they are interconnected through communication channels to ensure data consistency and enable distributed operations.
Once you’ve decided the type of database you want to use, you can determine the type of architecture you want to use. The architecture of a database varies significantly based on the needs of the organization, the type of data being managed, and the specific applications that interact with the database.
A database management system acts as an intermediary between the user and the database, ensuring that the data is easily accessible, consistently organized, and securely maintained. The effectiveness of a DBMS hinges on its underlying architecture, which must be robust, scalable, and capable of handling various data-related tasks with efficiency.
The primary functions of a DBMS include:
From simple structures that manage daily transactions in a small business to complex architectures that handle more unstructured and real-time data in large enterprises, the spectrum of database architecture is broad and diverse, and has evolved rapidly over time.
It started with flat file systems as early as the 1950s, where data was stored as plain text or binary files for simple retrieval. There were no established relationships between the different entities, which made it somewhat difficult to query.
To cater to this, hierarchical and network databases came around the late 1960s. These databases introduced the parent-child and many-to-many relationships. However, due to rigid schema and complex navigation (tree), it was still not easy to query the data.
Next came the relational databases that introduced the normal form of data—i.e., first normal form, second normal form, and third normal form. This ensured that the data was separated and structured correctly. These systems dominated the enterprise systems in the 1970s and 1980s for their reliability and consistency.
As businesses started going digital, there arose a need for analysing historical data and analytical processing, for which traditional databases offered OnLine Analytical Processing (OLAP) and data warehousing. This helped with business intelligence and reporting.
With the increase of social media and web users, there was a need for more flexibility in storing and handling huge amounts of data (big data), which traditional relational databases could not provide.
This led to the rise of modern NoSQL databases in the 2000s. These databases introduced horizontal scalability and enabled flexible storage for unstructured/semi-structured data.
Further enhancements in the database architecture were inevitable due to the increasing number of use cases for data, catering to real-time and streaming data, and cloud-native and serverless databases that revolutionized the usage of databases, from merely performing CRUD operations to transforming and analysing data with the data layer itself.
Further trends include support for AI-optimized databases that can perform vector search, AI/ML integration, and augmented querying and retrieval.
The four basic components of all types of database architecture, SQL or NoSQL, include a user (web user, application, business analyst, database administrator), query processor, storage manager, and the physical database itself. The query processor, storage manager, and other subsystems—like indexing, transaction management, concurrency control, and logging—constitute the database management system.
A user can be a web/internet user, a developer wanting to extract data from the database, a business analyst trying to pull statistics, or a database administrator monitoring logs and access control.
A query processor performs the following functions:
A storage manager performs the following tasks:
The physical storage is the layer where the actual database resides to store the data, important statistics about that data and queries, execution plans, logs, and indexes.
The database design process, from concept to implementation, involves a set of meticulous steps:
Note that as business requirements change, the database schema needs to evolve to accommodate the changes without having to make too many edits to the application’s code as well as the existing schema. For this, a database like MongoDB, with a flexible and evolving schema, is a much more suitable option.
One of the fundamental aspects of database architecture is how the data is organized, stored, accessed, and retrieved within a database system.
Broadly, we split the types of database architecture models into two categories:
In this section, let’s understand the physical or tier architecture, along with some more modern DBMS architecture models.
The most basic architecture is the client server architecture, which includes one-tier, two-tier, and three-tier architecture. In a client server architecture, there is a client (end user or application) that requests services from the server (backend or database). The server in turn processes the request and returns the appropriate response.
In the one-tier architecture, the database, user interface, and application logic all reside on the same machine (local machine) or single server itself. It's typically used for small-scale applications where simplicity and cost-effectiveness are priorities. Because there are no network delays involved, this type of tier architecture is generally a fast way to access data.
In a two-tier architecture, one or more clients connect directly with a database server—for example, a desktop application connecting to a single database hosted on an on-premises database server like an in-house customer relationship management (CRM) that connects to a Microsoft Access database.
Most modern web applications use a three-tier architecture. In a three-tier architecture, the clients connect to a backend application server, which in turn connects to the database. The application is split into three or more layers—i.e., a presentation layer, business application layer, and data layer—creating a separation of responsibility. Using this approach ensures more security, scalability, and faster deployment.
Security: Keeping the database connection open to a single back end reduces the risks of being hacked.
Scalability: Because each layer operates independently, it is easier to scale parts of the application.
Faster deployment: Having multiple tiers makes it easier to have a separation of concerns and to follow cloud-native best practices, including better continuous delivery processes.
Much suited for modern applications, a distributed database architecture distributes the data across multiple nodes, through various methods like replication and sharding, to ensure high availability and fault tolerance.
Further enhancing the distributed architecture is the cloud-based architecture, where the database acts as a service provided over the cloud and offers more flexibility and scalability, and is cost effective. MongoDB Atlas is a good example of a cloud-based data platform.
In a federated architecture, multiple autonomous databases can be integrated into a single view, thus integrating data from multiple diverse sources into one database. MongoDB Atlas provides Data Federation, where you can access and query multiple Atlas databases and get the result into the desired platform.
MongoDB was launched in 2009 and became a trailblazer for modern distributed applications that would eventually work in tandem with the modern technologies, be it cloud or AI. MongoDB is built on the document model and retains the best of relational and NoSQL databases.
MongoDB replaced rows in tables of a relational database, with flexible documents that are easy for data retrieval and querying. In MongoDB, data that is accessed together is stored together. Some prominent features of the MongoDB database are:
MongoDB’s distributed architecture makes it scalable, resilient, and mission critical. Further, MongoDB Atlas, the software as a service offered by MongoDB, supports additional services, including real-time analytics data workloads, stream processing, and vector search.
Almost all modern distributed applications today follow a three-tier architecture, and MongoDB fits naturally into it. Full technology stacks, like the MEAN stack, MERN stack, and FARM stack, use MongoDB as their backend database.
For detailed architecture, refer to the MongoDB Architecture Guide.
Explore the work of the MongoDB Systems Research Group.
Database architecture describes how a database management system (DBMS) will be integrated with your application. When designing a database architecture, you must make decisions that will decide how your applications are deployed and maintained.
Database architecture is based on the client server architecture, from which many architectures have further evolved. The main database architecture types are one-tier, two-tier, three-tier, distributed, cloud-based, and federated architecture.
There are many different ways to architect a DBMS solution, as given below:
The four components of a database structure are: