Data Storage – User's blog

Since your “Digital Cookbook” already has an elegant dining room (Frontend), an efficient kitchen powered by AI agents (Backend), and a reliable waiter (API), it’s time to take care of the element without which none of these pillars could function smoothly: the pantry. In this chapter, I’ll introduce you to databases, which act as containers where we store our data.

Data Storage System (Our Pantry)

What are databases, and why are they essential for building applications? You might think that it’s convenient to store everything in files on your computer, but if we chose to keep our data that way, problems would quickly arise.

Files (Sacks of Recipes):

Storing data in files on your computer is the simplest solution you can choose. It feels intuitive because, by using a computer, we’ve naturally learned how to work with files. But does simple always mean good? Not necessarily. Everything works fine if you only have three dishes that you eat all the time. In that case, storing data in files is a great solution. It’s simple, fast, and it’s easy to find whatever you need provided it’s one of those three dishes. In practice, however, almost no one limits their diet to just three repeating meals. For example, if you wanted three different meals per week, you would already have to search through twenty-one files, and nearly a hundred in a month. At that point, things start to get complicated and this is exactly where databases make the problem much easier to solve.

Databases (Labeled Recipe Shelves):

As mentioned in the previous section, databases are used to store various types of information we want to keep, such as recipes, shopping lists, or even photos of our dishes. What’s more, they not only store data but also make it much easier to search through it, eliminating the problem we encountered when using files.

The Role of the Database in the Application Lifecycle

The Pantry as a “Single Source of Truth”

A database is a fundamental component of any modern web application because it allows us to see what actually exists, for example, in the recipe we’re looking for. Most of us would agree that adding fish to carbonara wouldn’t be a great idea just like leaving out sugar when making egg cream. Databases ensure that nothing appears in a recipe that shouldn’t be there, and that nothing essential is missing (assuming, of course, that the recipe was entered correctly). From a technical perspective, this means that if a process expects a specific piece of data, it will be available as long as it exists in the database.

The Great Book of Recipes

A database not only ensures that nothing unwanted ends up in the wrong place, but thanks to constraints, it also prevents us from adding data that would only make things harder. For example, a recipe without preparation steps, or one without a title and an image describing what it is.

Which Database? (How to Equip Our Kitchen)

As mentioned earlier when discussing file-based storage, things are not always as simple as they seem. The same applies here. Even though a database is an essential part of an application, not every option will fit your project well. Just like in a pastry shop, a whole cabinet full of pepper would not be very useful and could even create confusion when looking for something you actually need. The same principle applies here. In theory, you can use any database, but it won’t always perform optimally in your system.

The table below presents the characteristics of the two most popular types of databases, which we will explore in more detail shortly.

FEATURE	SQL DATABASE	NoSQL DATABASE
TYPE	Relational database	Non-relational database
STRUCTURE	In SQL databases, data is stored in tables with a fixed number of columns	Non-relational databases can have structures such as document, graph, or key-value
DATA STRUCTURE TYPE	Fixed data structure	Flexible data structure
SCALABILITY	Vertical	Horizontal
QUERIES	Usually SQL	The way queries are made depends on the specific NoSQL database. There is no single declarative query language
MOST IMPORTANT FEATURES	Integrity, consistency, and data stability	Scalability, flexibility, and fast queries

SQL Databases (Your Organized Inventory Ledger)

In the world of databases, there are two main types: SQL (Structured Query Language), which we will focus on in this chapter, and NoSQL, which we will discuss shortly.

Relational Databases

The relational data model can be thought of as a well-organized recipe binder, where each row represents a specific dish entry, and columns are fixed fields such as the author’s name, ingredients, or preparation time. A table is a clear section within this kitchen binder where rows and columns are organized together.

Columns: In a database, they store a single type of value, such as the author’s name or ingredients.
Rows: They describe the different attributes of a single item, for example a recipe. This means that a single row contains the recipe ID, the author’s name, as well as the ingredients and cooking time.
Tables: A combination of columns and rows that represents a single type of data.

To illustrate this concept, a table has been prepared in an Oracle relational database. The table includes two example records, which are structured sets of data.

The four columns in our example table are as follows: ID, which is the unique identifier of the recipe in the database, AUTHOR_NAME, which is simply the name of the person who added the recipe, INGREDIENTS, which is the list of products needed to prepare the dish, and PREP_TIME, which is the time required to prepare the dish in minutes.

The rows contain two example recipes, which we read from left to right. The recipe with ID 1 was created by Anna. To prepare it, we need pasta, tomatoes, garlic, and olive oil, and the preparation takes about 25 minutes.

	ID	AUTHOR_NAME	INGREDIENTS	PREP_TIME
1	1	Anna	pasta, tomatoes, garlic, olive oil	25
2	2	Tomek	pizza dough, tomatoes, garlic, olive oil, salami	25

The immense popularity of relational databases comes from several factors, such as:

Easy retrieval of information, for example finding all recipes that contain tomatoes, which can be done using SQL queries.
Combining data from different tables, for example if we know that Anna makes excellent main courses but her desserts are not as good, we can easily filter recipes to show only the main dishes she has prepared.
Maintaining consistency through clearly defined relationships between tables, for example if a recipe author changes their last name, it is automatically updated across the entire database.
And, importantly, efficient handling of large datasets. Even if our cookbook contains thousands of recipes, we can easily find exactly the ones we are looking for.

NoSQL Databases (A Flexible Pantry of the Future)

Now that we understand relational SQL databases, let’s look at another popular option, NoSQL databases. While the relational model is like a structured binder with fixed forms, the NoSQL model, in this case a document database, can be imagined as a creative notebook where each recipe is a separate, flexible note. This allows us to avoid enforcing a rigid structure, so one recipe might include only steps, a title, and ingredients, while another can also include the story behind the dish, explaining where it comes from and how it reached the person who decided to share it.

A collection is the equivalent of a table in a relational database. In this case, you can think of it as a “drawer” where various notes are stored. In a single drawer, you can keep both simple sandwich recipes and complex cake instructions with a list of many sub-ingredients.
Fields: These are individual pieces of information stored as key–value pairs, for example “Name: Pizza” or “Time: 30”. These fields can vary greatly and do not have to appear in every note.
Documents: These are individual recipe entries. Unlike a row in a table, a document can contain nested lists, such as a list of spices, or smaller notes, such as a sauce recipe, which allows us to build a hierarchical structure.

To illustrate this concept, an example document has been prepared in a document database (MongoDB), stored in JSON format. It contains two records:

{
  "id": 1,
  "author_name": "Anna",
  "ingredients": ["pasta", "tomatoes", "garlic", "olive oil"],
  "preparation_time": 25
}
{
  "id": 2,
  "author_name": "Tomek",
  "ingredients": ["pizza dough", "tomatoes", "garlic", "olive oil", "salami"],
  "preparation_time": 25,
  "additional_info": {
    "difficulty_level": "medium",
    "favorite_for_children": true
  }
}

As you can see, the record with ID 2 has a completely different structure than the one with ID 1, which clearly demonstrates the flexibility of NoSQL databases.

Caching (A Handy Shelf on the Counter)

Now that we have our pantry (the database), it’s time to ask a question: is it worth going down to the basement for every pinch of salt? The answer is, of course, no. That’s exactly what caching is for.

Caching involves storing the most frequently needed data closer to those who request it, significantly increasing access speed.

If we assume that in our kitchen the database is the pantry, then the cache is the shelf on the kitchen counter. Instead of constantly going back to the pantry for salt or pepper, which slows down cooking, we keep them right in front of us.

To ensure your restaurant runs efficiently, we use three main layers for serving ready-made results:

Guest’s pocket (Browser Cache): The guest keeps the menu and contact details with them, so they don’t have to ask the waiter for them during the next visit.

Local food stand (CDN): Distributed locations around the world that serve images of dishes from nearby, so a hungry guest doesn’t have to wait for a response from your main kitchen.

Cheat sheet on the chef’s counter (In-memory cache/Redis): A small note with the most important instructions, allowing the chef to answer common questions in milliseconds without flipping through the “Great Book of Recipes” in the basement.

Since space on the counter is limited, you need to use cleanup strategies (cache eviction):

LRU: You put back into the pantry the items you haven’t used for the longest time.

Random Replacement: The “crazy chef” throws out a random jar when there is no more space.

TTL: You attach an expiration timer to a note, after which it is discarded so that you always work with fresh data.

Thanks to this multi-layered approach, your kitchen can serve millions of guests while maintaining a pace worthy of a Michelin star.

Summary

In summary, a well-functioning pantry, the database, is the foundation of every professional kitchen, ensuring secure storage of information about products, orders, and customers. By introducing caching, our handy shelf on the counter, we make the most frequently needed data always available, allowing us to serve ready-made results quickly without unnecessary trips to the basement.

However, even the most impressive kitchen with a fully stocked pantry won’t serve a single meal if the power goes out or the oven stops working. In the next chapter, we will explore the world of DevOps, where you will learn how to automate the process of delivering results and how to ensure that your “restaurant” remains available to users 24/7, regardless of load.

In the next chapter, you will learn how to automate delivery processes (CI/CD) so that chefs can focus on cooking instead of manually checking every dish. We will also look at containers (Docker), which ensure that your dishes taste the same in every part of the world. In addition, you will learn what Git is, an intelligent recipe journal where many chefs can work on their creations at the same time, as well as Kubernetes, a reliable floor manager that immediately replaces a faulty table when something goes wrong. You will see that building and maintaining an application is one cohesive process handled by the entire team.

Materials

Self-study materials that are related to this topic: