What is a Database?
The definition, the internals, the Indian companies using them, and why SQL is the most valuable skill you can learn in tech
// Part 01
The Definition — And Why Every Other Explanation Fails
Search "what is a database" and you will find answers like "a structured collection of data" or "software for organising information." These are not wrong. They are useless. A notebook is a structured collection of data. A filing cabinet organises information. What makes a database fundamentally different from every other way humans have stored data is not what it holds — it is what it guarantees.
Here is the definition that actually explains it:
A database is a structured collection of data managed by software that guarantees: every read gets the correct data, every write either fully succeeds or fully fails, multiple users never corrupt each other's changes, and committed data survives any crash — all simultaneously, at any scale.
Every word of that definition is doing work. Let us go through it.
"Every read gets the correct data" — when your Razorpay app shows your account balance, it must show the real current balance — not a stale version from 3 seconds ago when another transaction was still in progress. Databases use a property called isolation to ensure you never see partial or in-progress data from another user's session.
"Every write either fully succeeds or fully fails" — if you transfer ₹1000 from your savings to your current account, two things must happen: ₹1000 leaves savings AND ₹1000 enters current. If the server crashes between those two steps, the database must undo the first step automatically. No half-executed operations. This is called atomicity.
"Multiple users never corrupt each other's changes" — right now, thousands of people are placing Swiggy orders simultaneously. Two customers might order the last item in a restaurant's inventory at the exact same moment. The database ensures exactly one of them gets it and the other sees "out of stock." Without this guarantee, both orders would go through and the restaurant would be in chaos.
"Committed data survives any crash" — the moment your UPI payment shows "Success," that record is permanent. Even if the bank's server loses power one millisecond later, the transaction is not lost. The database writes to a log on disk before confirming success — if it crashes, it replays the log on restart. This is called durability.
Together these four guarantees are called ACID — Atomicity, Consistency, Isolation, Durability. You will learn them deeply in Module 47. For now, know this: every reliable software system you have ever used runs on a database because of these four guarantees. Nothing else provides them.
// Part 02
What Is Happening Inside — The Internals That Make Everything Click
Most SQL tutorials skip this section entirely and jump straight to SELECT. That works until something goes wrong and you have no idea why your query is slow, or why two rows disagree, or why an index helps. Ten minutes understanding the internals will make you a permanently better SQL writer.
Data lives in pages on disk
When you create a table and insert rows, the database does not write one file per row. It groups rows into fixed-size blocks called pages — typically 8KB or 16KB each. Every read and write to the database happens in units of pages, not individual rows. When you query for one customer, the database loads the entire page containing that customer's row into memory, then finds the row within it.
This is why column data types matter even for beginners. If you define a column as VARCHAR(1000) when your data is never more than 50 characters, you waste space on every page, meaning fewer rows fit per page, meaning more pages to load, meaning slower queries. Good data type choices are a performance decision, not just a semantic one.
Indexes — the reason SQL is fast at all
Without an index, finding a customer by email in a table with 10 million rows requires the database to scan every single page from start to finish. On a table of that size, that takes seconds. With an index on the email column, the database maintains a separate sorted data structure called a B-tree that lets it jump directly to the right page in microseconds — the same way a book's index lets you jump to the right page instead of reading every word.
The difference between a query with and without an index on a 10-million-row table is not 10% faster — it is often 1000× faster. You will build indexes in Module 46 and learn exactly when to add them and when they hurt rather than help.
The buffer pool — why RAM size matters
Reading from disk is roughly 100,000 times slower than reading from RAM. So the database keeps recently accessed pages in a memory area called the buffer pool. When you run the same query twice in quick succession, the second run is often dramatically faster because the pages are already in memory — no disk read needed. This is why a database server with more RAM handles more queries without slowing down. It fits more of its "hot" data in the buffer pool.
The Write-Ahead Log — how data survives crashes
Before the database writes any change to the actual data pages, it first records the change in a separate sequential file called the Write-Ahead Log (WAL). Only after the log entry is safely written to disk does the database confirm the write succeeded. If the server crashes mid-operation, the database reads the WAL on restart and either completes or undoes the interrupted operation. This is the mechanical reason why "committed data survives any crash" is a guarantee, not a hope. It is also why databases recover cleanly from power cuts that would leave a spreadsheet file permanently corrupted.
// Part 03
Tables, Rows, Columns, Primary Keys and Foreign Keys
A relational database stores all data in tables. A table holds exactly one type of thing. FreshMart has a table for customers, a separate table for orders, one for products, and so on. You never mix two types of things in the same table — that single rule is the most important design principle in all of SQL.
Rows and Columns
Columns are the fields — the specific pieces of information you track about that type of thing. Rows are the individual records — one row per instance. In the FreshMart customers table, columns include first_name, city, and loyalty_tier. Each row is one specific customer.
Primary Keys — Every Row's Unique ID
Every table must have a column whose value is unique for every row and is never NULL. That column is called the Primary Key. In FreshMart's customers table, customer_id is the primary key. No two customers can ever share the same customer_id. The database enforces this automatically — if you try to insert a second customer with customer_id = 1, it will throw an error and reject the insert.
Primary keys are almost always integers that auto-increment — the database generates 1, 2, 3, 4... automatically every time a new row is inserted. You never type a primary key value manually. The database does it for you. This means every customer, every order, every product always has a unique identifier you can refer to precisely — no ambiguity, no duplicates.
Foreign Keys — How Tables Connect to Each Other
The power of a relational database comes from linking tables. The orders table has a column called customer_id. This is a Foreign Key — it stores the primary key value of a row in another table, creating an enforced link between them. Order 1001 has customer_id = 1. That 1 means Aisha Khan placed this order. The database enforces this link: you cannot insert an order with customer_id = 999 if no customer with id 999 exists. This prevents orphaned records — orders that point to nobody.
orders.order_id ←—— order_items.order_id
order_items.product_id ←—— products.product_id
orders.store_id ←—— stores.store_id
employees.store_id ←—— stores.store_id
employees.manager_id ←—— employees.employee_id
// Part 04
Excel vs Database — The Honest, Complete Comparison
Excel is a genuinely great tool for reports, budgets, and exploring small datasets. The problems start at scale, at concurrency, and at reliability. Here is every dimension where they differ:
| The problem | Excel | Database |
|---|---|---|
| Scale | Hard limit of ~1 million rows per sheet. Swiggy crosses that before 9 AM every day. | Billions of rows. PostgreSQL runs production tables with hundreds of billions of rows. |
| Concurrent users | One person can edit at a time. Two people saving simultaneously corrupts the file or silently overwrites each other's changes. | Thousands of simultaneous connections. Each gets an isolated session. Changes never conflict. |
| Data type enforcement | Anyone can type "two hundred" into a price column. No enforcement — one bad entry breaks every formula downstream. | Types enforced at the engine level. Inserting text into an INTEGER column throws an error before the data is saved. |
| Query speed | VLOOKUP across 1 lakh rows takes 10–30 seconds. Filters and pivot tables on large datasets lock the file for minutes. | A properly indexed query on 100 million rows returns in under 100 milliseconds. |
| Connecting related data | VLOOKUP by ID across sheets — breaks when row order changes, requires manual maintenance in every file. | Foreign keys enforce links permanently. Change a customer name once — every table referencing that customer reflects it. |
| Application connectivity | Cannot be queried by an app programmatically while open. No concept of concurrent API access. | Applications connect via a network protocol. 10,000 simultaneous app connections are routine. |
| Crash recovery | If Excel crashes mid-save, the file may be permanently corrupted. No recovery guarantee beyond the last manual save. | The Write-Ahead Log guarantees committed data survives any crash. Zero data loss on recovery. |
| Access control | Password-protect the whole file or nothing. No column-level or row-level permissions. | Row-level security, column masking, role-based access. An analyst can see sales but not salaries. Enforced by the engine. |
// Part 05
What 'Relational' Actually Means — And the Databases Indian Companies Use
The databases you will use SQL on are called Relational Database Management Systems (RDBMS). The word "relational" confuses beginners because it sounds like it means the tables are related to each other. That is true, but it is not the origin.
In 1970, an IBM researcher named Edgar Codd published a landmark paper proposing that data should be stored as mathematical relations — a formal term for a table with rows and columns, with specific mathematical properties that guaranteed consistency. The word stuck. A relational database means: data in tables with rows and columns, tables linked through keys, queried using SQL. MySQL, PostgreSQL, Oracle, SQL Server, and SQLite all qualify.
What the leading Indian tech companies actually run
Razorpay, CRED, Zerodha, Groww, Meesho
Open source with zero licensing cost. Handles complex queries, concurrent writes, and JSONB for semi-structured data. Default choice for high-growth fintech and e-commerce startups.
Swiggy, Nykaa, OYO, MakeMyTrip
Extremely mature, massive community, dominates high-traffic consumer apps. Swiggy uses MySQL for core order management because of its proven replication and read-scaling.
HDFC Bank, ICICI, Infosys clients
Enterprise support contracts, Windows Server integration, strong compliance tooling. Standard in Indian banking where RBI-regulated downtime has legal consequences.
TCS, Wipro clients, IRCTC, LIC
Dominant in legacy enterprise and government. IRCTC runs one of the highest-transaction-volume Oracle databases in Asia. Expensive but deeply entrenched.
Inside every mobile app
Serverless, zero-configuration, runs on the device itself. Every Android and iOS app — including Swiggy, PhonePe, CRED — has an SQLite database storing local data.
// Part 06
The FreshMart Database — Your SQL Dataset for All 62 Modules
Every single module in this course — from Module 01 to Module 62 — uses the same database: FreshMart. A fictional Indian grocery chain. 10 stores across Bangalore, Hyderabad, Mumbai, Delhi, Chennai, Pune, and Ahmedabad. Real Indian brands — Amul, Tata, Nestle, Britannia, P&G. Realistic prices, realistic data.
You will know this database so well by Module 62 that you could rebuild it from memory. That depth of familiarity with one dataset is intentional — every query you write will feel meaningful, not academic.
20 customers across 7 Indian cities. Bronze, Silver, Gold, Platinum loyalty tiers. Joined dates from 2020–2023.
30 orders from January–March 2024. Statuses: Delivered, Processing, Cancelled, Returned. UPI, Card, COD, NetBanking.
118 line items. Which products were in each order, at what quantity, with what discount.
25 products — Amul Butter, Maggi, Parle-G, Head & Shoulders, Fortune Oil. Across Staples, Dairy, Beverages, Personal Care.
10 stores: ST001–ST010. Each with a city, manager name, opening date, and monthly revenue target.
15 employees with roles, salaries, hire dates, and a self-referencing manager_id for the org hierarchy.
The tables connect exactly as a real business does. A customer places an order. The order is at a store. The order has items. Each item is a product. Each store has employees. Employees have managers — who are also employees. One real-world event, six coordinated tables. You will learn to query across all of them.
// Part 07
The Live SQL Playground — Run Queries Right Now
Every module in this course has a live SQL playground. The FreshMart database is loaded and ready the moment the page opens — no install, no account, no cloud. It runs entirely in your browser using DuckDB-WASM.
Do not worry about understanding the syntax below yet. That starts in Module 05. For now, click Run and see real FreshMart data appear.
Try changing LIMIT 10 to LIMIT 20 and clicking Run again. That is your first SQL experiment — you just filtered a live database.
That second query joins two tables, filters by status, groups by city, and sorts by revenue. You will write queries like this yourself by Module 31. For now just notice: one SQL query answered a business question that would have taken 10 minutes of VLOOKUP in Excel.
// Part 08
What This Looks Like at Work — A Full Day
You join PhonePe as a Business Analyst, three months after completing this SQL course. Here is what a real working day looks like.
🎯 Pro Tip
In most Indian tech companies, the ability to query data independently — without waiting for a data engineer to pull it for you — is the single biggest differentiator between a junior analyst and a senior one. Every product, growth, ops, finance, and marketing role uses SQL daily. It is the highest return-per-hour skill you can learn in the first year of any tech career.
// Part 09
Interview Prep — 5 Questions With Complete Answers
A database is a structured collection of data managed by a Database Management System that provides four guarantees a spreadsheet cannot: atomicity (every write fully succeeds or fully fails), consistency (data always satisfies defined rules), isolation (concurrent users never see each other's in-progress changes), and durability (committed data survives any crash). Together these are called ACID properties.
The practical differences are significant across three dimensions. First, scale: a spreadsheet hard-limits at roughly one million rows and degrades long before that. A database handles billions of rows without degrading — PostgreSQL production tables with hundreds of billions of rows are common. Second, concurrency: two people saving the same spreadsheet simultaneously corrupts it. A database uses transaction isolation to safely handle thousands of simultaneous write sessions. Third, integrity: a spreadsheet allows any value in any cell. A database enforces data types, foreign key relationships, and custom constraints at the engine level — bad data is rejected before it is saved.
In practice, databases power every application — every tap on a mobile app reads or writes to a database. Spreadsheets are for reporting and analysis on small exported result sets, not for storing the data itself.
A primary key is a column or combination of columns whose value uniquely identifies each row in a table. The database enforces two constraints on a primary key column automatically: every value must be unique — no two rows can share the same primary key — and no value can be NULL. These constraints cannot be violated by any INSERT or UPDATE.
Every table needs a primary key for three reasons. First, without a unique identifier there is no reliable way to update or delete a specific row. If two customers have the same name and city, which one do you update? The primary key makes the answer unambiguous. Second, other tables reference the primary key through foreign keys — the orders table knows which customer placed an order by storing that customer's primary key value. Without a primary key, no foreign key relationship can exist. Third, the database automatically creates a B-tree index on the primary key, making lookups by primary key extremely fast regardless of table size.
In practice, primary keys are almost always auto-incrementing integers — the database generates 1, 2, 3... automatically on each insert. You never manually type a primary key value.
A foreign key is a column in one table that stores the primary key value of a row in another table, creating an enforced relationship between the two. In FreshMart, the orders table has a customer_id column that references customers.customer_id. The database enforces this: any insert into orders must provide a customer_id that already exists in the customers table. An insert with customer_id = 9999 when no customer 9999 exists will fail immediately.
The problem foreign keys solve is called referential integrity — ensuring relationships between tables are always valid. Without foreign keys, you could insert orders pointing to customers who do not exist, delete customers who still have orders referencing them, or end up with thousands of orphaned records that point to nothing. When you later join orders to customers, those orphaned rows silently disappear from the results with no error message — a data quality disaster that is extremely difficult to debug.
Foreign keys also define the structure of every JOIN query you will write. When you join orders to customers, you join on the foreign key relationship: ON orders.customer_id = customers.customer_id. Understanding foreign keys is the foundational prerequisite to writing any correct JOIN.
RDBMS stands for Relational Database Management System. The word "relational" comes from relational algebra — a mathematical framework proposed by Edgar Codd at IBM in 1970. In mathematics, a "relation" is a set of tuples (rows) with named attributes (columns). Codd proposed that all enterprise data should be stored in this tabular form with specific mathematical operations — selection, projection, join — used to query it. SQL is essentially a user-friendly syntax for those relational algebra operations.
Practically, a database is relational when it stores data in tables with rows and columns, enforces relationships between tables through keys, supports SQL as the query language, and guarantees ACID properties. MySQL, PostgreSQL, Oracle, SQL Server, and SQLite are all RDBMS.
MongoDB is not relational — it stores JSON documents rather than rows in tables, making it a "NoSQL" database. It trades ACID guarantees and the relational model for flexible schema and horizontal scaling. The relational model dominates structured business data because of its consistency guarantees and the expressive power of SQL for ad-hoc analysis. Knowing SQL means you can work with any RDBMS, because the core language is 95% identical across all of them.
Razorpay uses PostgreSQL as its primary transactional database. PostgreSQL is the dominant choice at Indian fintech startups because it is open source with no licensing cost, handles complex query patterns that payment processing requires, provides JSONB columns for storing semi-structured payment metadata alongside structured transaction records, and has a strong track record of ACID compliance at high concurrency. Every rupee transferred through Razorpay touches a PostgreSQL transaction.
Swiggy uses MySQL for its core order management and logistics systems. MySQL has been proven at extreme transaction volumes in food delivery. Its read-replica architecture lets Swiggy route millions of "check my order status" queries to read replicas while reserving the primary database for writes — ensuring that peak dinner-time load does not overwhelm a single server. MySQL's maturity and the size of its ecosystem also mean Swiggy can hire engineers who already know it.
HDFC Bank runs Microsoft SQL Server across much of its core banking infrastructure. SQL Server's enterprise support contracts, deep integration with Windows Server, and long track record with the kind of compliance and audit tooling that RBI-regulated institutions require make it the standard choice in Indian banking. The licensing cost is significant but acceptable when database downtime has direct regulatory and reputational consequences. HDFC also uses Oracle for certain legacy systems — Oracle remains dominant in Indian banking, insurance, and government despite its cost.
// Part 10
Errors You Will Hit — And Exactly Why They Happen
🎯 Key Takeaways
- ✓A database is a structured collection of data managed by a DBMS that guarantees ACID: Atomicity (writes fully succeed or fully fail), Consistency (rules always hold), Isolation (concurrent users never see each other's in-progress changes), Durability (committed data survives any crash).
- ✓Internally, databases store data in fixed-size pages on disk, use B-tree indexes for fast row lookups, keep frequently-accessed pages in a memory buffer pool, and use a Write-Ahead Log to survive crashes without data loss.
- ✓Excel breaks at scale across 8 dimensions: row limits, no concurrency, no type enforcement, slow queries, fragile cross-sheet links, no app connectivity, no crash safety, and no row-level access control. Databases solve all eight.
- ✓Every table needs a Primary Key — a column whose value uniquely identifies each row. The database enforces uniqueness and non-nullability automatically. Almost always an auto-incrementing integer.
- ✓Foreign Keys create enforced links between tables. You cannot insert a row that references a parent that does not exist. This prevents orphaned records and is the foundation of every JOIN query you will write.
- ✓RDBMS (Relational Database Management System) is the category that MySQL, PostgreSQL, Oracle, SQL Server, and SQLite belong to. SQL is the standardised query language for this model — 95% identical across all of them.
- ✓In Indian tech: PostgreSQL is default at fintech startups (Razorpay, CRED, Zerodha). MySQL dominates high-traffic consumer apps (Swiggy, Nykaa). MS SQL Server is standard in banking (HDFC, ICICI). SQLite runs inside every mobile app.
- ✓FreshMart — 6 tables, 218 total rows, realistic Indian data — is the dataset for all 62 modules. Learn it once and use it for every single query in the course.
- ✓A live SQL playground powered by DuckDB-WASM runs on every module page. Zero install, zero account, zero server — the FreshMart database is pre-loaded and ready the moment the page opens.
- ✓SQL is not just a "data" skill. Every product manager, growth analyst, operations lead, and finance analyst at every Indian tech company uses SQL daily. It is the highest-return technical skill learnable in under 3 months.
What comes next
In Module 02, you go inside the database — how primary keys and foreign keys are defined in code, what constraints are and how they enforce data quality automatically, and why the decisions you make about table structure before writing a single query determine how well everything downstream works.
Module 02 → How Databases WorkDiscussion
0Have a better approach? Found something outdated? Share it — your knowledge helps everyone learning here.