🗄️ SQL vs NoSQL Under the Hood

About this simulation

Every database makes a trade-off between how it indexes data, how it spreads data across machines, and how strictly its replicas must agree before a write is considered "done." This lab renders three real storage architectures side by side so those trade-offs become visible instead of abstract.

How it works

• PostgreSQL — a query walks down a B-tree index (root → branch → leaf) to find a pointer into the row heap, then fetches the row from disk-backed storage. This costs O(log n) index hops plus a heap fetch.
• MongoDB — a mongos router hashes the query's shard key and forwards it directly to the shard holding that range of documents, so only one shard is touched per query.
• Redis — the dataset lives entirely in RAM as a flat hash table; any key maps straight to a bucket in O(1), with no tree walk and no disk seek — the reason Redis reads are so fast.
• Toggling Strong consistency makes every replica acknowledge a write before it completes (higher latency, no stale reads); Eventual lets replicas catch up asynchronously (lower latency, brief staleness) — the classic CAP theorem trade-off.

Controls

• Database engine — switches the entire storage structure between PostgreSQL, MongoDB and Redis.
• Query rate — how many query pulses per second are fired at the primary node.
• Replica nodes — number of follower/secondary nodes that must receive each write.
• Shard count — number of MongoDB shards the document set is partitioned across.
• Strong / Eventual — replication consistency mode, changes replica sync delay and read latency.

Did you know?

PostgreSQL's default B-tree index keeps lookups at roughly 3-4 hops even for millions of rows, because each internal node fans out to hundreds of children — that's why "logarithmic" index scans stay fast at huge scale.