PM & AI Chronicles

From Product Thinking to Prompt Engineering – One Tool at a Time

Database Foundations 🧱 🛢️: Key Concepts & When to Use Them 📝🔓

This article is part of the Database Fundamentals Series — where we break down what databases are, how they store information, and how data is organized, accessed, and used behind the scenes. 👉 — Database Fundamentals: Foundation of Data Storage

When most people hear the word “database,” they immediately imagine something that looks like an Excel worksheet — rows and columns neatly arranged in a grid. And that’s actually a great starting point. Think about a simple spreadsheet where you store:

  • EmployeeID, Name, Phone Number, Email
  • Or a product sheet with Part Number, Description, Quantity, Price
  • Or a list of Appointments with Date, Customer, Service, Notes

Each of these spreadsheets is made up of columns (types of data) and rows (actual records).

A database works in a very similar way… with one important difference: In a real database, this structure is called a table, not a worksheet.

Where Excel is excellent for small, manual, human-editable lists, databases are built for much larger, structured, reliable, multi-user systems—the kind used by websites, apps, banks, hospitals, and e-commerce platforms.

Later, you can even import data directly from Excel into a database application like Microsoft Access, SQL Server, MySQL, or PostgreSQL.

Databases can have multiple related tables, each storing one specific type of data. These tables can link to one another through relationships, letting you manage far more complex systems without duplicating data everywhere. This is one of the biggest advantages databases have over spreadsheets.

Imagine you run an IT company and store employee info in Excel. 📄 In Excel (Flat File): You have a single sheet like:

EmployeeIDNameDepartmentManagerLocation

Now, imagine 50 employees belong to the Engineering department. If tomorrow the Department Name changes from “Engineering” to “Software Engineering,” you would have to manually:

  • Search for all rows with “Engineering”
  • Update them one by one
  • Hope you didn’t miss any
  • Hope nobody typed “Engg.” or “engineering” in lowercase

This is slow, error-prone, and frustrating.

You’d have:

  • Table 1: Employees
    EmployeeID, Name, DepartmentID, LocationID
  • Table 2: Departments
    DepartmentID, DepartmentName, ManagerID

Now, if the department name changes? You update ONE row in the Departments table.

Every employee linked to that department automatically reflects the new value — instantly and accurately.

  • No manual search.
  • No human error.
  • No duplicates.
  • No inconsistencies.

That’s the power of non-flat, relational database design.

You should use a database whenever your data needs to be shared, updated reliably, or scaled beyond what a simple spreadsheet can handle. In other words, the moment your information becomes too complex or too busy for flat files, a database becomes essential. Below are common real-world scenarios where a database is the right choice:

If many people need to access or update the same data at the same time, you need a database.

Flat files (like Excel):

  • Don’t handle simultaneous editing well
  • Usually allow only one writer at a time
  • Lock the entire file whenever someone makes a change

This means that if one user is saving, everyone else waits — which doesn’t work for active teams or fast-moving data.

Databases, on the other hand:

  • Lock data at the record level, not the entire file
  • Allow dozens, hundreds, or even tens of thousands of users to work at once
  • Are designed for high concurrency

📌 Note: Modern collaboration tools (like Excel Online, Google Sheets) appear to let multiple users edit at the same time, but that’s due to the collaboration software, not the spreadsheet format. Behind the scenes:

  • Each user is working on a separate copy
  • The system tracks edits
  • Changes are merged using timestamps

The spreadsheet app itself has no awareness of multi-user editing.

If your data or user base grows, a database is the right choice.

Flat files degrade quickly because:

  • They are designed for single-user scenarios
  • They slow down when data grows large
  • They become unstable as multiple users try to access them

Databases like Microsoft SQL Server or Oracle are engineered for performance at scale:

  • They can handle hundreds, thousands, or tens of thousands of users
  • They maintain reliability even with massive datasets
  • Enterprise editions can distribute or replicate data across on-prem servers and cloud environments

📌 For example: Microsoft SQL Server supports up to 32,767 concurrent connections — something no spreadsheet could ever approach.

Similar to scalability, databases are significantly faster than flat files when processing or accessing large amounts of data. Database software is highly optimized and memory-intensive, which means:

  • Having plenty of RAM on the database server is critical.
  • Speed improves even more when the database files and log files are stored on SSDs rather than HDDs.

While large SSDs can be expensive or harder to find for massive databases, the performance difference is undeniable. Databases are built for speed — spreadsheets are not.

Spreadsheets are excellent for storing numbers and simple text, but they struggle beyond that. Try storing:

  • High-resolution images
  • Long paragraphs or full documents
  • Audio files
  • Complex structured data

Even if you somehow embed these items, spreadsheets don’t have a reliable way to describe, search, or organize them. Databases, however, can store virtually any type of data:

  • Text
  • Numbers
  • Images
  • PDFs
  • Videos
  • JSON documents
  • Binary objects (BLOBs)

And unlike spreadsheets, databases can index and retrieve this information quickly and consistently.

Excel worksheets have strict built-in limits:

  • Maximum rows: 1,048,576
  • Maximum columns: 16,384
  • Maximum characters per cell: 32,767

This might sound like a lot, but it becomes tiny when you think about large organizations like Amazon, Walmart, or Bank of America — companies that deal with millions or even billions of records every day.

In these environments, a spreadsheet simply cannot store or manage that much data. Databases, however, are designed to handle massive record counts efficiently and reliably.

Users expect their information to be stored safely and permanently — a concept called data persistence. Both spreadsheets and databases save data to a hard drive, so in theory, they both provide persistence. But the difference becomes clear when something goes wrong.

If you are entering data and the computer suddenly loses power, any changes made since your last manual Save are lost. That could be minutes or even hours of work gone in an instant.

Databases are designed to protect your data continuously:

  • Changes are saved automatically as each field is edited
  • Every update is also written to special log files
  • If the main data becomes corrupted, the log files can be used to rebuild or restore missing information

Because of this, databases offer much stronger data persistence than spreadsheets — making them far more reliable for important or business-critical information.

Flat files (such as Excel spreadsheets) are typically intended for local storage. This limits how many people can access them and from where. If the file lives on your laptop, only you—or someone you email it to—can use it.

Databases, however, offer much greater flexibility:

  • They can be stored on a local machine (offline).
  • They can be hosted on a server inside an organization.
  • They can be placed in the cloud, where users can access them from anywhere.

These options dramatically improve data availability, meaning the information is accessible to authorized users at any time, from any location, without relying on a single person’s computer.

Databases provide far more granular security than spreadsheets. With a spreadsheet, security is very basic:

  • Either a user can open the file and see everything,
  • Or they cannot open it at all.

There’s no easy way to hide certain rows, columns, or records from specific people. Databases, however, allow precise control. You can grant permissions at many levels:

  • Specific tables
  • Specific columns
  • Even specific rows of information

Example: In a company’s Employee database:

  • HR staff can see salary, performance reviews, and personal details.
  • Managers can see only the employees in their own department.
  • Regular employees can see only their own information.
  • IT staff may have access only to technical details like login status, not salary or personal data.

All of this is controlled automatically by the database’s security rules — something spreadsheets simply cannot do.

Large organizations often rely on shared, centralized databases that support the entire company rather than just a single team. These systems are usually part of Enterprise Resource Planning (ERP) platforms that bring together data from departments such as finance, HR, sales, supply chain, and operations.

Enterprise databases act as a single source of truth — meaning all teams work with the same accurate, consistent data. They also support huge user counts, complex workflows, and strict security requirements. This ensures that critical information is always reliable, protected, and available whenever the business needs it. Common enterprise database platforms include:

  • SAP
  • Workday

They combine data from multiple departments into a single unified system, giving teams a complete and consistent picture of the business.

These databases are built to handle enormous amounts of data and thousands of users simultaneously without slowing down.

Enterprise systems include advanced controls for validating data, managing user permissions, encrypting sensitive information, and recovering from failures.

They power essential applications like CRM, ERP, HR systems, supply-chain tools, and other core processes the business depends on every day.

Enterprise databases can manage many types of information — from structured tables to documents and unstructured data — and adapt to specific organizational needs.

They are designed to seamlessly connect with other software tools, enabling smooth data exchange across applications, departments, and cloud/on-prem systems.

Modern databases generally fall into two major categories: relational (SQL) and non-relational (NoSQL). Each is designed to handle different kinds of information and workloads.

Relational databases store information in tables made up of rows and columns — very similar to spreadsheets, but far more powerful. They use SQL (Structured Query Language) to insert, update, and query data. They remain the dominant choice for enterprise systems because they enforce structure, consistency, and strong data integrity.

NoSQL databases don’t rely on tables. Instead, they store data in more flexible formats, such as documents, key-value pairs, graphs, or wide-column stores.
They are ideal for handling unstructured or semi-structured data, which makes them especially useful today, since a vast portion of modern data (including video, audio, images, logs, and social media content) does not fit neatly into tables.

👉 In fact, a significant share of today’s data is unstructured, with video alone accounting for nearly half of all global data generation.

Databases are everywhere — behind websites, mobile apps, online shopping, banking systems, hospitals, and even simple signup forms. While spreadsheets are great for small, personal tasks, databases shine when information needs to be shared, protected, organized, scaled, and accessed reliably across many users and systems.

In the next article, we’ll look at how databases connect information using relationships and why this model is used almost everywhere. 👉 Relational Databases