A technical deep-dive compares how MySQL and PostgreSQL execute index scans. MySQL's InnoDB uses a clustered index where secondary indexes store the primary key, requiring two B-Tree traversals. PostgreSQL stores a tuple ID (TID) pointing directly to the heap, needing just one B-Tree traversal and a constant-time heap fetch.

The real-world performance isn't purely theoretical. MySQL often feels faster on small to medium datasets where its clustered index provides better locality and sequential access. PostgreSQL scales better with very large tables, many secondary indexes, and random access patterns. Its pointer-based access and index-only scans become decisive advantages in complex analytics workloads.

PostgreSQL's index-only scan is a key differentiator. By including the queried column (e.g., `age`) in the index, it can return results without touching the heap at all. MySQL's secondary indexes lack row version visibility info, making a true index-only scan impossible. For simple OLTP, MySQL excels; for complex queries and large-scale data, PostgreSQL's efficiency wins.