In this series, I aim to explain what a graph database is in a way that is understandable not only for those new to software engineering but also for people coming from other industries.
In this second article, I will introduce different types of databases.
Over time, various types of databases have been developed. Let’s take a look at some of the major categories.
The most widely used and historically significant type of database today is based on the relational data model, which was proposed in 1970 by Edgar "Ted" Codd. The theory of relational data modeling came first, and then various relational databases were developed to implement it.
In a relational database, data is represented as a collection of relations (tables) made up of tuples (rows). Due to its high expressiveness and versatility, the relational model outperformed alternative approaches such as the network model and the hierarchical model. The adoption of SQL (Structured Query Language) further contributed to its widespread use.
In 2007, with the introduction of MongoDB, document-oriented databases emerged. The catchy term NoSQL fueled interest in these databases as potential alternatives to traditional RDBMS.
By the early 2010s, the importance of scalability became increasingly apparent due to the explosion of data. Document databases matched this need well. In a document-oriented database, a document serves as both the data and its schema, making it possible to horizontally distribute data across multiple physical servers.
For startups that need to quickly adapt to changing requirements, the rigid schema constraints of the relational model can be a hindrance. Document databases, which allow more flexible schema management and easier scaling, were well-suited for such fast-moving environments.
Of course, as document databases became more widely used, their limitations and constraints also became evident. However, the emergence of document databases provided new perspectives and alternatives, which was a boon for the software industry, where diverse business needs must be implemented efficiently.
Neither relational databases nor document databases are inherently superior. The choice depends on the problem being solved and the system requirements.
Theoretically, any application that can be implemented using a relational database can also be implemented with a document database, and vice versa. However, when factors such as query performance, scalability, and operational costs are taken into account, the optimal solution varies case by case.
The skills of the development team also play a crucial role. If your team is well-versed in relational databases, maintaining and operating an RDBMS might be a more practical choice.
To reiterate, this is not about which type of database is better—it’s about selecting the right tool for the job.
From a software engineering perspective, having a broader toolset allows for greater flexibility in designing applications. Being proficient in different types of databases is not only intellectually stimulating but can also expand career opportunities and lead to new innovations.
Are relational and document databases enough to cover all use cases? What about column-oriented databases or streaming databases?
The database landscape is vast, and each type is designed for specific scenarios. While we could continue exploring other types, it's time to focus on graph databases.
In the next article, we will dive into graph databases.