Every hotel page on this site tells you how far it is to the nearest airports, stations, venues and landmarks, and how long it takes to get there by car or on foot. It looks like a small line of text. It is quite complicated, it is the biggest piece of computing the site does, and it needs hours of computer time every night, on one computer on my desk.
The problem is the size of the table
There are 107,586 hotels in my catalogue, and 10,171 places worth travelling to: 3,252 airports, 5,277 landmarks and 1,642 venues. Every hotel against every place is about 1.1 billion pairs. Measuring a real route for each one, turn by turn, is out of the question, and almost all of those pairs are pointless: nobody staying in Brighton needs a drive time to Narita.
So the work is cut down in three ways before a single route is measured:
- Only what a page can show. For each hotel I keep the places its own page could list: the nearest 12 venues and landmarks, and up to 18 nearby airports. That takes a billion pairs down to a few million at most.
- Only airports that matter. A hotel's two nearest airports are always measured, however far away they are. That matters in the Highlands or the Australian outback, where the nearest airport might be 150 km off and it is still the one you will use. Beyond those two, an airport more than 20 km away gets a plain straight-line distance, labelled as such. Nobody in central London needs a turn-by-turn time to Southend.
- Only what changed. Once a pair is measured it stays measured. A night's work is the new hotels, the new or moved places, and nothing else.
Real roads, not crow-flies
The routes come from OpenStreetMap, the map anyone can edit, and Valhalla, an open-source routing engine. I keep the world as 100 regional road maps on a portable drive: 303 GB of it. To measure a region, its map is loaded into a router and asked for drive and walk times from each place to the hotels around it, a few thousand pairs per request.
The machine doing this is an Apple M4 with 10 cores and 16 GB of memory. A single region's router can need 3 to 4.5 GB on its own, so the work runs one region at a time. Britain and Ireland, the region I watch most closely, took 55 minutes today to re-measure 81 places. The big regions (the United States, India, Germany, France) take far longer, and work through their backlog a few hours each night.
It runs between 2am and 5.30am, and only when nobody has touched the computer for 15 minutes. If I am working late, it waits for the next half-hour and tries again.
What happens when the map is wrong
Maps are made by people, and routers are literal. An airport's pin usually sits in the middle of the airfield, which a router snaps to the nearest road. At London City that was an airside road with no public way out, so every drive time from it came back empty. At Heathrow the router decided the pin was on a piece of road not connected to anything else.
For those, I now ask an AI model where the public drop-off and the terminal entrance are, and then the router has to agree: it must find a public road at the drop-off and drive from it to nearby hotels at believable speeds before the point is used. Tonight that checked 456 airports and fixed 324 of them, for $2.42 in total. When the router disagrees, the airport keeps what it had and goes on a list for me to look at by hand. Frankfurt and Hong Kong are on that list as I write.
Counting hotels nearby
The other half is counting: how many hotels are within reach of a place, which decides whether a landmark or a stadium gets its own page. That used to mean loading the whole catalogue into memory and measuring every distance.
The site's database is Postgres, run by Neon, which charges for the time the database spends awake and working. That makes it a tough system to run cheaply: every call wakes it up, and a page that asks a dozen small questions costs a dozen times over. So a lot of my work goes into asking it less.
This week I switched on PostGIS, the geography extension for Postgres, and built a spatial index over every hotel's position. Now "how many hotels within 5 km of this stadium" is one question the database answers from the index, instead of my code fetching the whole catalogue to count it. The answers are then kept for a while (ten minutes for most counts, half an hour for city totals, six hours for "priced recently") so the same question is not asked again on the next page view. When nobody is visiting, the database is left alone to sleep.
What it costs you
Nothing at the moment you load a page. Every figure is worked out in advance and stored, so a hotel page just reads its travel times from the database. The only thing fetched live is the price, because a price from yesterday is not a price.
Where I have no measured route, the page says so: you see a straight-line distance with the words "straight-line" next to it, never an estimate dressed up as a drive time.
Figures taken 21 October 2026.