Database In-Depth | Part -1

Surendiran -


One of the most common things we hear today is:

"Don't worry, it's all in the cloud."

It almost sounds like our data is floating somewhere in the sky, ready to be accessed from anywhere, by anyone, at any time - like Magic.

The Reality is simple :
Whether you're running a database on your laptop, a Raspberry Pi, a home server, a virtual machine, Kubernetes, or even a cloud provider, your data eventually lives on a physical storage device - an SSD or HDD.

Btw, Cloud is simply someone else's computer.

No magic. Just CPUs, memory, disks, and a lot of clever engineering in between.There's no abstraction that erases physics. Bits still have to be written to spinning platters or flash cells somewhere, on some rack, in some building.

Why I'm Writing This Series

As someone working with databases every day, I realised that we spend a lot of time writing SQL, creating indexes, and tuning queries, but we rarely stop to ask:

  • Where is my data actually stored?
  • How does the database find a row so quickly?
  • Why is disk I/O such a critical factor in database performance?
  • What exactly is a database page?
  • How are tables and indexes physically organised?
  • These questions led me down the rabbit hole of database internals.

So I decided to document my learning journey.
This won't be a theoretical series. Instead, I'll explore how databases work from the ground up, explaining concepts as I learn them and connecting the common pattens on it to real-world database operations....

Terms to understand :

To understand how databases store the data. We need to go back to the history of computers & How computers can handle the data. We all know computers can only understand 0 & 1’s.


Bit : A bit(binary digit) is the smallest unit of data that a computer can process and store. The bit is represent by a single binary value, 0 or 1.
Byte: A byte is a sequence of eight bits that are treated as a single unit. The byte referencing to a computers memory and storage.

I believe now we understand about a bit & byte in computers.Let's dive more deeply to understand how does it actually store the decimal & data into binary.

How does a bit works?

Each bit in a byte is assigned a specific value, which is referred to as the place value. A byte's place values are used to determine the meaning of the byte as a whole, based on the individual bits.

Mmm, Okay Now that we know how a byte's bits combine into a decimal number, the next question is: how does a computer turn that number into a letter you can read on screen?

That's where ASCII (American Standard Code for Information Interchange) comes in. ASCII is a character encoding standard - it's simply an agreed-upon mapping between numbers and characters. Every typed English character, digit, and symbol is assigned a specific decimal value between 0 and 127.

A quick example:

Character:  H    e    l    l    o
Decimal:    72   101  108  108  111
Binary:     01001000  01100101  01101100  01101100  01101111

That's literally how the word "Hello" lives on your disk - five bytes, each one a number, each number mapped to a letter.

Binary is precise, but it's painful to read and write - 01010011 is a lot of digits for one character. This is why you'll almost never see raw binary when inspecting real data (hex dumps, memory addresses, debuggers). Instead, you'll see hexadecimal.

Since a byte is 8 bits, it always maps to exactly 2 hex digits. Let's convert "S" example:

S = 01010011
↓ split into nibbles
0101   0011
↓ look up
  5      3
→ 0x53

So 01010011 (83 in decimal) becomes 0x53 in hex - much shorter to read, and the reason you'll see byte values written like 0x53, 0xFF, or 0x00 throughout database internals, debuggers, and disk dumps.

At this point, we've gone from a single bit all the way to representing readable text:

  • Bit → the smallest unit, 0 or 1
  • Byte → 8 bits, decoded using place values
  • ASCII → gives bytes meaning as characters
  • Hex → a compact, human-friendly way to write those bytes

This is the foundation everything else in database internals sits on.

THE DATABASE STACK

SQL Layer -> Storage Engine -> Operating System -> Hardware

This post covers the bottom layer - bits and bytes on hardware

Your SQL queries, your indexes, your transactions - all of that sits at the top. But every single one of them eventually comes down to bytes being written to and read from physical hardware, which is exactly what we just spent this whole post unpacking.

Coming up in Part 2, we'll move one level up and look at how those bytes get organized into rows - how databases lay out fixed-width fields inside a page, how a slot array keeps track of where each row lives, and how a single bit can mark a column as NULL instead of wasting space storing "nothing."

If you made it this far - thanks for reading. See you in Part 2.