What is a Database?

I bet you had a notebook during your childhood which had all the GTA cheatcodes written. If you ever wanted to unlock unlimited health, you opened that notebook, went through it and found the cheat code to use.

That right there is a database. Data requested, answer received. In this scenario, your notebook was the database.

Let's say you're building an application, you store your user's information in a `txt` file on your system, when they login, you open the file, search through it one by one and then match the email id and password and they login. Works like a charm right? (Don't say yes)

This approach works fine if you're planning to cater to almost 10 people. What's the issue with the 11th, you may ask? The issue is whenever someone tries to login, you open the text file in your code, you go line by line and see if the email id and password entered matches with what data we have on that line. For 11 users this might take microseconds or milliseconds (assuming you don't mess up the code :/). Now think about this setup for 10,000 users, 100,000 users, or even 1 million users.

Your code will literally take seconds or minutes to just check if the password is correct or not. What if two people sign up at the exact same moment and both try to write to the file? What if your server crashes halfway through saving someone's data and the file gets left in a broken state? What if you want to find every user who signed up last week? Your file system cannot handle these operations optimally.

So what is the way out? You stop building stuff? Thankfully you don't have to stop yourself from building the next best Todo list (If you're considering building this, please don't.)

Some geniuses from the past took the same file system we use daily and added an intelligent software layer on top of it so the data you're adding becomes organised. This combination of intelligent software in front of a file system is what we call a Database.

A database is organised storage that lets you save data and get it back quickly, reliably, and without things breaking as you grow.

The important word there is organised. Your text file stored data too, but it had no structure, no shortcuts, no rules. A database stores your data and keeps it arranged in a way that makes finding things fast, handles multiple people reading and writing at the same time, and makes sure nothing gets corrupted when things go wrong.

At the end of the day, a database is still just files sitting on a disk somewhere. Take that software away and you're back to a text file. The software is the whole trick.

Now you might ask, okay but how exactly does it find things fast? Great question.

The answer is Indexes. The simplest way to understand an index is to go back to our text file.

Imagine your `users.txt` file has 10 million users.

Without an index, if someone tries to login using `[email protected]` your code starts from the top:

• [email protected]
• [email protected]
• [email protected]
• ...and keeps checking one by one until it finally finds the correct entry.

That process is called a full scan.

Now imagine instead you maintained another file beside it:

• a → starts at line 0
• b → starts at line 12000
• c → starts at line 27000
• s → starts at line 6100000

Now when someone logs in with `[email protected]`, you don't start from line 1 anymore. You jump directly near the section where emails starting with "s" exist and continue searching from there.

That shortcut is basically what an index is. You just invented one. Congratulations, you're basically a database now.

A database builds and maintains these shortcuts automatically. So when you search for a user by email, it doesn't scan every row from the top. It uses the index to narrow down where the data exists and reaches it incredibly fast. One user among a billion, found in milliseconds.

This is why the software layer matters so much. Your text file couldn't build an index. A database maintains one automatically, keeps it updated every time data changes, and uses it every time you ask a question.

Turns out software has different storage needs too, just like the people building it. So people built different types of databases. The difference is really just in how they store data in the file system and how they retrieve it.

Here are some of the most common ones (won't cover every type because it is not really needed):

Relational Databases (SQL)

The vanilla of databases, the default choice for every application when you're starting out (not if you're a MERN developer). Data is stored in tables with rows and columns, exactly like a spreadsheet. The "relational" part means different tables can be connected to each other. Your Users table links to your Orders table, your Orders table links to your Products table, and you can ask questions that pull from all of them at once.

Document Databases (NoSQL)

Instead of strict tables, these store data as flexible objects, essentially JSON. One user can have 3 fields, another can have 30, and the database is completely fine with that. This makes them great for situations where your data doesn't have a fixed, predictable shape. If you're a MERN developer, welcome home, this is MongoDB.

Key-Value Stores

The simplest model of all. You store something under a key, and you get it back using that key. That's it. No tables, no documents, no joining things together.

What they lack in flexibility they make up for in pure speed. These are used for caching, session storage, and anywhere you need to read and write small pieces of data incredibly fast. Redis lives here, and it's running quietly in the background of pretty much every large app you use daily.

Every app that remembers anything is using one of these. Your messages, your feed, your bank balance, the username you picked in 2014 (hello cooldude6969).

The database is never the part you see. It's just the reason the answer is always there when you need it.