Index Race
Same query, 200,000 rows, one index. This is real PostgreSQL running inside your browser, so the times below are measured on your device.
What just happened?
Your browser downloaded PGlite, a WebAssembly build of PostgreSQL. It created a table with 200,000 synthetic candidates, then searched for one email 7 times and took the median.
Without an index, PostgreSQL does a Seq Scan: it reads every row until it finds a match. With an index on the email column, it does an Index Scan: it walks a small tree straight to the row.
Open the real query plans under the result to see both. Nothing is pre-recorded, and no server is involved.
Why does this matter?
This gap is why apps feel fine in a demo and slow in production. With a few hundred rows, a full scan is instant. With millions, the same query locks up pages. I hit this on a production recruitment platform, where key pages took 5 to 40+ seconds under load.
When should you not add an index?
Every index has a cost: writes get slower and it uses disk space. Index the columns your queries actually filter, join or sort on, and check with EXPLAIN ANALYZE that PostgreSQL really uses it.
Built by Bilel Abdelmoula
Full-stack developer from Oran, Algeria. I work on React, PostgreSQL, APIs and AI, and I'm available for remote roles and freelance work.