The planner turns estimated row counts into a cost using a handful of configuration settings: seq_page_cost (1.0) for a page read in order, random_page_cost (4.0) for a page read out of order, cpu_tuple_cost (0.01) per row processed, and effective_cache_size, its guess at how much of the data is already in memory. Those defaults describe a spinning disk, which is why a database on SSD can wrongly believe index access is four times more expensive than it is. Knowing the settings exist explains why the planner keeps choosing a sequential scan on hardware where an index would win.
PostgreSQL turns its guess about how many rows a query will touch into a cost, and it does that with a few numbers you can see and change. Reading a page in order counts as 1.0, reading one out of or…