Most developers use databases every day. Few actually understand what happens under the hood. We say things like “the database stores data” or “the query is slow”—but inside a real database engine, there is a complex, carefully engineered …

Sichere Programmierung dev.to 31.01.2026, 11:28 Uhr 4 Min. Lesezeit KRITIS / Energie

↗ Quelle (dev.to)

Reagiere als Erste:r — dein Feedback zählt!

Most developers use databases every day.

Few actually understand what happens under the hood.

We say things like “the database stores data” or “the query is slow”—but inside a real database engine, there is a complex, carefully engineered system built for performance, durability, and correctness.

This article explains how real databases work internally, step by step, without marketing language or oversimplified myths.

1. A Database Is Not a Spreadsheet

A real database is not:

A giant table in memory

A collection of CSV files

A simple key-value map

A real database is a storage engine + execution engine + transaction system, tightly integrated.

At a high level, every serious database has:

Parser

Planner / Optimizer

Execution Engine

Storage Engine

Buffer Cache

Transaction Manager

Recovery System

Let’s walk through what actually happens.

2. What Happens When You Send a Query?

When you run:

SELECT name FROM users WHERE age > 30;

The database does not immediately scan a table.

Instead, it follows a strict pipeline.

Step 1: Parsing

The SQL text is converted into an Abstract Syntax Tree (AST).

The database checks:

Syntax correctness

Valid table and column names

User permissions

At this stage, it does zero execution.

Step 2: Query Planning & Optimization

This is where databases become serious engineering.

The query optimizer decides:

Which indexes to use

Join order

Scan method (index scan vs sequential scan)

Cost estimation based on statistics

Example decisions:

Is it cheaper to scan 1 million rows sequentially?

Or to use an index with random I/O?

Modern databases use:

Cost-based optimizers

Statistics (histograms, cardinality)

Rule-based rewrites

This step determines performance more than hardware.

3. The Execution Engine

After planning, the database produces an execution plan.

The execution engine:

Pulls rows through operators (scan → filter → project)

Uses iterators or vectorized execution

Streams results instead of loading everything into memory

Important concept:

Databases process data in pipelines, not all at once.

4. How Data Is Actually Stored on Disk

Databases do not store rows directly on disk.

Pages (Blocks)

Data is stored in fixed-size pages (commonly 4KB–16KB).

Each page contains:

Page header

Row slots

Metadata

Pages are the minimum unit of I/O.

Row Storage vs Column Storage

Row-oriented (PostgreSQL, MySQL):

Best for OLTP

Fast inserts and point queries

Column-oriented (ClickHouse, Redshift):

Best for analytics

Excellent compression

Vectorized scans

5. Indexes Are Not Magic

Indexes are separate data structures, usually:

B-Trees (most common)

Hash indexes

LSM Trees (RocksDB, Cassandra)

A B-Tree:

Keeps data sorted

Minimizes disk seeks

Balances read/write costs

Important truth:

Indexes speed up reads but slow down writes.

Every insert/update must update:

Table data

All related indexes

6. Memory Is a Cache, Not the Source of Truth

Databases never trust memory.

Buffer Pool (Cache)

Frequently used pages are cached in RAM

Dirty pages are written back later

Replacement strategies (LRU variants)

If power fails:

Memory is lost

Disk must still be consistent

Which brings us to the most critical system.

7. Transactions and ACID

Real databases guarantee ACID:

Atomicity

Consistency

Isolation

Durability

This is achieved through:

Write-Ahead Logging (WAL)

Before modifying data:

Changes are written to a log

Log is flushed to disk

Only then is memory updated

If the database crashes:

WAL is replayed

Data is recovered

Logs are more important than data files.

8. Concurrency Control (Why Locks Exist)

Databases support thousands of concurrent users.

They use:

Locks (row, page, table)

MVCC (Multi-Version Concurrency Control)

With MVCC:

Readers don’t block writers

Writers create new versions

Old versions cleaned by vacuum/GC

This is why:

PostgreSQL can read without locking

Oracle and PostgreSQL scale well under load

9. Recovery and Crash Safety

When a database restarts after a crash:

Read last checkpoint

Replay WAL records

Undo incomplete transactions

Restore consistency

This process is deterministic and repeatable.

No guessing. No heuristics.

10. Why This Knowledge Matters

Understanding internals helps you:

Write faster queries

Design better schemas

Choose correct indexes

Avoid dangerous assumptions

Debug performance issues

Most “slow database” problems are:

Bad query plans

Wrong indexes

Misunderstanding internals

Not hardware.

Final Thought

A real database is closer to an operating system than a library.

It manages:

Memory

Storage

Concurrency

Recovery

Scheduling

If you treat it like a black box, it will punish you.

If you understand it, it becomes one of the most powerful tools in software engineering.

CTI Threat Relationship Graph2 Knoten / 1 Relationen

CVE / Incident Software MITRE ATT&CK CWE Weakness IoC

IR-PLAYBOOK-RCEHIGH

Schritte anzeigen

SOC Incident Playbook: Remote Code Execution (RCE) Defense

WAF MitigationSofort

Virtuelles Patchen am Reverse Proxy / WAF für gefährdete URL-Pfade und Payloads aktivieren.

SecRule REQUEST_URI "@rx ..." "id:1001,phase:1,deny,status:403"

Web Shell ScanSofort

Web-Root auf neu angelegte Scripts, anomal modifizierte Dateien und Persistence scannen.

find /var/www -type f -name "*.php" -mmin -120

Outbound FilteringSofort

Ausgehenden Datenverkehr (Reverse Shells zu unbekannten IPs/Ports) blockieren.

ss -tunp | grep -E ":(4444|1337|8080|9001)"

Vendor Patching

Hersteller-Update in Staging validieren und schnellstmöglich in Produktion ausrollen.

apt update && apt --only-upgrade install <pkg>

1-Click Detection Engineering: Multi-Dialect SIEM Rules5 Formate

Regeln anzeigen

Syntax validiert (0 Fehler)

title: Detect Exploitation - How Real Databases Work Internally ?
id: 1ecc1e74-3c72-42dc-ace9-c7f8cf62c7e0
status: experimental
description: Automatisch generierte SIEM-Erkennungsregel basierend auf CTI Intelligence
references:
  - https://tsecurity.de/
author: iShareStuff CTI Automated Detection Engine
date: 2026-09-24
logsource:
  category: network_connection
  product: any
detection:
  selection:
      CommandLine|contains:
        - 'exploit'
  condition: selection
falsepositives:
  - Legitime administrative Zugriffe oder Penetrationstests
level: high
tags:
  - attack.initial_access

Syntax validiert (0 Fehler)

rule CTI_Threat_Indicator {
    meta:
        author = "iShareStuff CTI Automated Detection Engine"
        date = "2026-09-24"
        description = "YARA Signature for "
    strings:
        $str = "How Real Databases Work Intern" ascii wide
    condition:
        any of them
}

Syntax validiert (0 Fehler)

index=security sourcetype IN ("cisco:asa", "pan:traffic", "zeek_conn", "suricata", "WinEventLog:Security")
("How Real Databases Work Internally")
| stats count earliest(_time) as first_seen latest(_time) as last_seen by src_ip, dest_ip, dest_host, signature
| eval first_seen=strftime(first_seen, "%Y-%m-%d %H:%M:%S"), last_seen=strftime(last_seen, "%Y-%m-%d %H:%M:%S")
| sort - count

Syntax validiert (0 Fehler)

message: "*How Real Databases Work Internally*"

Syntax validiert (0 Fehler)

CommonSecurityLog
| where Message has "How Real Databases Work Internally"
| summarize EventCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by SourceIP, DestinationIP, DestinationPort, Activity
| extend DetectionRule = "iShareStuff-CTI-Compiled"
| sort by EventCount desc

🎯

MITRE ATT&CK Matrix Navigator 14 Taktiken

Reconnaissance

Resource Development

Initial Access

Execution

Persistence

Privilege Escalation

Defense Evasion

Credential Access

Discovery

Lateral Movement

Collection

Command and Control

Exfiltration

Impact

💡 Tipp: Klicken Sie auf eine TTP, um Gegenmaßnahmen und SIEM-Erkennungsregeln anzuzeigen.Enterprise Matrix v14.1

🚀 Auf tsecurity.de entdecken

◀ VORHERIGER BEITRAG 1 Min

CIO코리아·데이터이쿠, 조찬행사 개최···‘에이전트 AI 실행과 거버넌스’ 방향 제시

IT Security Nachrichten

NÄCHSTER BEITRAG 2 Min

Why I Built a Multi-LLM Development Framework (And Why You Might Need One Too)

Sichere ProgrammierungWeiterlesen ▶

Blättern: Pfeiltasten [ ← ] [ → ] · Tasten j / k · mobil: Wischen

Fokus-Vektor:

Kognitive Analyse für identifizierte Bedrohung: Erhöhte Bedrohungslage im Bereich How Real Databases Work Internally ?.... Basierend auf 368k Vektor-Korrelationen werden sofortige Isolationsmaßnahmen für betroffene Endpunkte empfohlen.

🛡️ Angriffsfläche & Exposure

Netzwerk/Remote-Zugriff ohne Vorauthentifizierung möglich.

⚡ Empfohlene Sofortmaßnahmen

1. Perimeter-Inspektion: Relevante Portfreigaben und exponierte Endpunkte unverzüglich scannen.
2. Patch-Applikation: Hersteller-Hotfix einspielen oder betroffene Daemons in isolierte DMZ-Segmente überführen.
3. Telemetrie & EDR-Alerts: Prozessaufrufe und Child-Processes auf anomale Shell-Spawns überwachen.

🔗 Semantisch verwandte Zero-Days MariaDB 11.7 VEC

Schnell-Prompts für Analysten

⚠️ DEFANGED SANDBOX VIEW (tsecurity.de): Alle Netzwerkindikatoren und URLs wurden neutralisiert (2 Indikatoren entschärft). Nur zur defensiven Analyse!

Format: python

#!/usr/bin/env python3
# Exploit Title: PoC for Target
import socket, sys
target = '192[.]168[.]1[.]10'
url = 'hxxp://target[.]local/vuln'
s = socket.socket()
s.connect((target, 80))
s.send(b'GET / HTTP/1.1\r\nHost: target.local\r\n\r\n')