Optimization tips for large datasets
By Nathan ColeUpdated
Routing24 has no stop limit on any tier. Plans of one to two thousand stops optimize in the browser, on your machine. This page covers how runtime scales, what a large optimization needs from the machine, and how to model and split large plans.
How runtime scales
Routing24 picks the time budget automatically from the plan size. The table below is a rough guide:
| Stops | Optimization time |
|---|---|
| ~10 | ~3 seconds |
| ~100 | ~30 seconds |
| ~1000 | ~5 minutes |
| ~2000 | ~15 minutes |
The metrics strip shows TIME LEFT while the optimization runs. There is no setting to trade time for quality. The budget scales with plan size. Run the optimizer covers the mechanics of an optimization.
Before the countdown starts, Routing24 fetches the travel-time and distance matrix for your locations from its servers. On large plans this preparation step adds a delay.
What the optimizer needs from your machine
The optimizer spreads the computation across parallel workers in your browser, using your CPU cores. In practice this means:
- Keep the tab open until the optimization finishes.
- Keep the machine awake. Sleep pauses the workers. A 15-minute optimization needs sleep disabled.
- Close the browser developer console. It can slow the optimization significantly.
- More cores help. A desktop optimizes a 2000-stop plan faster than a laptop. Other heavy tabs compete for the same cores.
Modeling large plans
At large scale, the data matters more than the hardware:
- Use Available count, not copied rows. Ten identical vans should be one Fleet row with Available: 10, not ten rows.
- Fewer distinct constraints. Every unique time window, tag combination, and per-order exception constrains the search further. Standardize where the business allows: one delivery window per customer group rather than a hand-picked window per order.
- Realistic shifts, not open-ended days. Tight but accurate shifts and windows narrow the search and produce routes drivers can complete.
- Accurate service times. On 1000 stops, an over-estimated service time of 5 extra minutes adds 80+ hours of nonexistent service time. Real orders then go unassigned. See Why an order went unassigned.
When to split the plan
Keep orders in one plan as long as they compete for the same vehicles. Split when they do not:
- By day. Orders for different days do not belong in one optimization. Multi-day planning with day offsets works, but if Tuesday's orders can never share a route with Monday's, two plans optimize faster.
- By area. If the north and south zones have dedicated fleets and no vehicle ever crosses over, they are two independent problems. Optimize them as two plans.
Do not split what shares vehicles: the savings come from the overlap between territories. A manual split removes that overlap from the search. To start a second plan from the same fleet, use Copy vehicles on the My Plans page.
Constraint mistakes are easier to spot on 50 stops than on 2000. When building a big plan for the first time, import a slice, optimize, check the result, then run the full set. See Import from Excel or CSV.
Next step
Reviewing a large routing plan uses the display controls and filter: Read the routing plan: ETAs, distance, load.
FAQ
Is there a limit on the number of stops?
Routing24 has no stop limit on any tier. Plans of one to two thousand stops optimize in the browser on your machine: around 100 stops take about 30 seconds, around 1000 stops about 5 minutes, and around 2000 stops about 15 minutes, plus the matrix preparation delay on large plans.
What does a large optimization need from my machine?
Keep the tab open until the optimization finishes and keep the machine awake, because sleep pauses the workers. Close the browser developer console, which can slow the optimization significantly. More cores help: a desktop optimizes a 2000 stop plan faster than a laptop, and other heavy tabs compete for the same cores.
How should I model ten identical vans?
Model them as one Fleet row with Available set to 10, not ten copied rows. At large scale the data matters more than the hardware: fewer distinct constraints, realistic shifts rather than open-ended days, and accurate service times narrow the search. On 1000 stops, 5 extra minutes of service time adds over 80 hours of nonexistent service time.
When should I split a plan in two?
Split only when orders do not compete for the same vehicles: different days that can never share a route, or areas with dedicated fleets where no vehicle crosses over. Keep everything that shares vehicles in one plan, because the savings come from the overlap and a manual split removes it from the search.