The short answer
A scrape of one category in one city — a few hundred businesses — is a small job by any measure. A scrape of a dozen categories across every city in a state is a large one, sometimes by two or three orders of magnitude. The gap between those isn't a MapsHarvest quirk; it's the same gap you'd expect between "look up one thing" and "look up ten thousand things." What changes the picture is how many of those lookups happen at once — which is a function of your plan, not your query.
What actually determines scrape speed
Search breadth
How many categories, multiplied by how many cities or states, you're asking MapsHarvest to cover. "Plumbers in Dallas" is one search. "Plumbers, electricians, and HVAC contractors across every city in Texas" is hundreds. This is the factor you control most directly, and it's the one that scales the job the most.
Concurrent workers
How many of those searches your plan can run at the same time instead of one after another. This is a named, plan-gated feature — it doesn't exist as a lever below the plan that includes it — so it's worth checking before assuming a big job will run the way a small one did.
What Google Maps itself returns
Response times for any given search or listing page aren't something any scraper — MapsHarvest included — controls. This is the one variable nobody can put a fixed number on, which is also why no honest answer to "how long will my scrape take" is a single number.
Concurrency is worth being specific about, because it's easy to assume every plan scales the same way and just gets throttled at the low end. It doesn't work like that here: 8 concurrent workers is a Scale-plan feature ($129/mo, 20,000 credits), and running your own dedicated worker on your own infrastructure is an Enterprise feature. Free, Starter, and Growth run a scrape through MapsHarvest's standard job pipeline — which is the right fit for the search sizes those plans are built for, but isn't the lever to reach for if your actual problem is "I need a 10,000-business, multi-state pull to finish faster."
Why filters don't speed things up
It's a reasonable assumption that adding a minimum-rating or has-website filter would make a scrape faster, since the final list is smaller. It doesn't work that way, and it's worth understanding why before you plan around it.
Filters run during the scrape, which is what makes them useful — you're only charged credits for businesses that actually match, instead of paying to scrape everything and then deleting rows yourself. But "during" means MapsHarvest still has to search the ground you asked for; the filter decides what makes it into your export, not how much territory gets covered. A "restaurants in Texas, minimum 4.0 rating, no website" search covers exactly as much of Texas as "restaurants in Texas" with no filters at all — it just hands back a shorter, more useful list at the end.
That's a genuinely good trade — you're not paying for leads you'd throw away, and you're not doing the filtering yourself in a spreadsheet afterward. It's just a different trade than "faster." If speed is the actual goal, the lever is search breadth and concurrency, covered above — not how tightly you filter.
How to estimate your own scrape
Rather than looking for a number that doesn't exist, it's more useful to size your own job against the two things that actually move it:
- Count your searches, not your expected leads. "Restaurants" in 5 cities is 5 searches. Add "cafes" and it's 10. Add 20 more cities and it's 150. This number — categories × locations — is what scales the job, not the filtered result count you're hoping to end up with.
- Decide whether concurrency changes your answer. If that number is small (a handful of searches), it runs through the standard pipeline and concurrency isn't a factor worth paying for. If it's in the hundreds — a real multi-state, multi-category pull — 8 concurrent workers on Scale is the difference between those searches running one after another and running in parallel.
- Check the credit estimate before you commit either way. The dashboard shows estimated credit cost up front based on your categories, locations, and filters, so you're not guessing at spend even though wall-clock time isn't the same figure.
Matching your scrape size to a plan
Free / Starter
A one-off pull — one category, a handful of cities, under a thousand results. Runs as MapsHarvest's standard job pipeline; there's no concurrency feature to configure at this tier, and for a search this size there's nothing to gain from one.
Growth ($49/mo)
Repeatable, mid-size scrapes you trigger via the dashboard or the REST API, often on a schedule you control yourself (a cron job, a Zapier schedule trigger). Webhook delivery means you're not sitting refreshing a dashboard waiting for it to finish either way.
Scale ($129/mo)
Large one-time pulls (a full state, multiple categories) or recurring scrapes where 8 concurrent workers meaningfully cut wall-clock time by running more of your search list in parallel instead of queued one after another.
Enterprise ($250+/mo)
Continuous, heavy-volume scraping where a local worker CLI runs on your own infrastructure — not sharing capacity with any other MapsHarvest customer's jobs — plus a dedicated CSM for the specific scale and data-residency needs that come with it.
FAQ
Does MapsHarvest show an ETA before I start?+
The dashboard shows your estimated credit cost before you run a scrape, based on your categories, locations, and filters. Credit cost and wall-clock time aren't the same number — a 2,000-credit scrape and a 2,000-credit scrape can take different amounts of time depending on how many workers are processing it.
Do filters make a scrape finish faster?+
Not directly. Filters (minimum rating, review count, has-website, has-phone) control which businesses end up in your final export and what you're charged credits for — they don't shrink the underlying search you asked for. A 'restaurants in Texas' search covers the same ground whether you filter hard or not; filtering just decides which of those results survive into your CSV.
Can I run more than one scrape at the same time?+
That depends on your plan's concurrency. Scale ($129/mo) is built around 8 concurrent workers specifically so multiple jobs — or one job split across more ground — can run in parallel instead of queueing. Enterprise goes further with a local worker CLI that runs on your own infrastructure, so your jobs aren't sharing capacity with anyone else's at all.
What's the single biggest lever I control?+
Search breadth — how many categories times how many cities or states you're asking for. Doubling your target list roughly doubles the work, regardless of plan. Concurrency changes how many of those searches run at once; it doesn't change how much searching your query actually requires.
Size up your own scrape for free
50 free credits, no credit card. Run a small search first to see the estimate before you plan a bigger one.