Most Scalable SERP APIs in 2026: Rate Limits, Throughput, and Cost at 10 Million Searches

The short answer: The SERP APIs with the highest self-serve throughput are Bright Data (no concurrency limit on any plan), Serper (up to 300 queries per second on a one-time $3,750 package), and Scrapingdog (up to 2,200 concurrent requests on its largest monthly plan). PrismCrawl allows 100 requests per second by default on its $1,000 package, which is 360,000 searches an hour, and runs custom plans at 1,000 or more requests per second, at least 3.6 million searches an hour. At 10 million searches a month, PrismCrawl is the least expensive provider in this comparison: about $1,500 of usage at $0.15 per 1,000, compared with $2,500 a month for Scrapingdog's Light API, $3,000 at Serper's lowest rate, and $6,000 or more at every other provider with public pricing at that volume.

This comparison is published by PrismCrawl, which is one of the providers compared. Rate limits and prices were checked against each provider's public pricing page or documentation on October 6, 2026. They are published defaults, not negotiated contracts, and we did not load-test other providers.

What makes a SERP API scalable

A SERP API that handles a 50-query demo can fall over at 5 million queries a day. For production workloads, five properties matter:

1. Throughput ceiling. How many searches per second, minute, or hour the plan accepts before returning 429 errors.
2. How the ceiling is tied to price. Some providers raise the limit with each package. Others cap hourly throughput at a share of the monthly quota, so a faster job requires a larger plan whether or not you need the extra searches.
3. Live or queued delivery. A live API returns results in the same request. A queued API accepts a task and delivers it later, which supports higher intake but adds minutes of delay.
4. What failures cost. At high volume even a 1% error rate is tens of thousands of requests a day. If the provider bills them, retries raise your effective price.
5. Cost at your real volume. The rate on the plan you would actually buy, including monthly resets or credit expiry.

Published SERP API rate limits

Providers express limits in different units, so the table shows each one as published and, where possible, the equivalent in requests per second.

A few notes on reading this table:

• DataForSEO allows one task per live call but up to 100 tasks per call in its standard queue, so queued intake can reach 200,000 tasks a minute. Queued results arrive after a delay, which suits batch rank tracking but not an application waiting on the answer.
• SerpApi and SearchApi scale hourly throughput with the monthly quota. SerpApi's $25 plan allows 200 searches an hour, and its 10 million search plan allows 200,000 an hour. A small, fast job on these services means paying for a large plan.
• Scrapingdog and Bright Data limit concurrent connections instead of rate. Requests per second then depend on response time, as explained in the section on concurrency below.
• PrismCrawl, Serper, and DataForSEO publish defaults and raise them for larger accounts, so treat the published number as the starting point for a high-volume account. PrismCrawl's custom plans run at 1,000 or more requests per second.

What 10 million searches a month costs, and how long it takes

The table below prices 10 million Google searches using each provider's published plans, and shows how long the batch takes at the plan's default limit. Monthly plans reset each month; prepaid credits carry over until they expire.

Oxylabs is left out because its largest self-serve plan stops at 8 million results a month and larger plans are not publicly priced.

Serper finishes the batch fastest at default limits, and PrismCrawl costs about half as much as Serper at this volume. If 28 hours at 100 requests a second is too slow for your window, a PrismCrawl custom plan at 1,000 or more requests per second runs the same 10 million searches in under 3 hours; email [email protected] with your expected volume and peak rate.

Rate limits, concurrency, and queues measure different things

A requests-per-second limit caps how often you can start a request. A concurrency limit caps how many requests can be open at once. Little's law connects the two: throughput equals concurrency divided by the average response time.

On a concurrency-limited plan, 400 concurrent requests at 2 seconds each produce about 200 requests per second. If response times rise to 4 seconds during a busy period, the same plan drops to about 100. On a rate-limited plan the arithmetic runs the other way: to sustain 100 requests per second at 4 seconds per request, your client needs about 400 requests in flight.

That has two practical consequences:

• Size your client to the limit and to the slow tail. Set in-flight requests to roughly the rate limit multiplied by the 95th percentile response time. Fewer, and you never reach your limit. Many more, and you hold open connections that add nothing.
• Compare like with like. A plan with 1,000 concurrent connections and a plan with 300 requests per second can deliver about the same throughput, depending on response time. Run the same workload on both before deciding which is faster for you.

Queued APIs separate intake from delivery. DataForSEO's standard queue can accept far more tasks per minute than its live endpoint can return, but you then poll or receive a callback when each task is ready. For a nightly rank-tracking job that is a good trade. For an AI agent or a user waiting on a response, only live throughput counts.

How to run a high-volume SERP pipeline

At production volume, most failures come from the client: unbounded bursts that trip 429s, retries that pile onto an already throttled account, and silent gaps where failed keywords never get re-queued. These practices keep a large job steady:

1. Spread requests evenly. Space request starts so you never exceed your per-second limit. Bursts trip 429s even when the average rate is fine.
2. Bound concurrency with a fixed pool of workers sized as described above.
3. Retry only what can succeed. Retry 429s and 5xx responses with capped exponential backoff and jitter, honoring Retry-After or the reset time the API returns. Do not retry 400-level validation errors.
4. Record every failure with its request ID so you can re-queue it and so support can trace it.
5. Check result shape as well as status codes. A 200 response with zero results or missing fields is a silent failure. See how silent scraper failures corrupt data.
6. Split work by priority. Keep interactive traffic on its own budget so a nightly batch never starves a user-facing feature.

Here is a minimal Python version using PrismCrawl's async client. The client already retries 429s, 5xx responses, and failed connections, and on a 429 it waits until the reset time the API returns. The code adds the even spacing, a bounded worker pool, and a failure log.

import asyncio
import time

from prismcrawl import APIConnectionError, APIStatusError, AsyncPrismCrawl

REQUESTS_PER_SECOND = 100  # your package's limit
WORKERS = 400  # about REQUESTS_PER_SECOND x p95 response time in seconds


class Pacer:
    """Spaces request starts evenly so bursts never exceed the rate limit."""

    def __init__(self, rate: float) -> None:
        self.interval = 1 / rate
        self.next_start = time.monotonic()
        self.lock = asyncio.Lock()

    async def wait(self) -> None:
        async with self.lock:
            now = time.monotonic()
            start = max(self.next_start, now)
            self.next_start = start + self.interval
        await asyncio.sleep(start - now)


async def worker(client, pacer, queue, results, failures):
    while True:
        keyword = await queue.get()
        try:
            await pacer.wait()
            response = await client.google.search(query=keyword, gl="us")
            results[keyword] = response["data"]["content"]["results"]
        except APIStatusError as error:
            failures.append((keyword, error.status_code, error.code, error.request_id))
        except APIConnectionError:
            failures.append((keyword, None, "connection_error", None))
        finally:
            queue.task_done()


async def run(keywords):
    queue = asyncio.Queue(maxsize=WORKERS * 2)
    results, failures = {}, []
    pacer = Pacer(REQUESTS_PER_SECOND)

    async with AsyncPrismCrawl(max_retries=4) as client:
        workers = [
            asyncio.create_task(worker(client, pacer, queue, results, failures))
            for _ in range(WORKERS)
        ]
        for keyword in keywords:
            await queue.put(keyword)  # waits when the queue is full, so memory stays flat
        await queue.join()
        for task in workers:
            task.cancel()

    return results, failures

The bounded queue keeps memory flat whether the keyword list has a thousand entries or ten million. Write failures to a file and run it again as its own batch once the main job finishes. For a full rank-tracking example with storage and change detection, see the SEO rank tracker guide.

Load-test a SERP API before you commit

Published limits describe what a provider allows. Your own workload decides what you actually see, so before moving production traffic, run a test that looks like your real job:

1. Use your real queries, including locations, devices, and page depth. Simple head terms are faster and more reliable than long-tail local queries.
2. Ramp in steps, for example 10, 25, 50, and 100 requests per second, holding each step for several minutes.
3. Measure the 95th and 99th percentile response time at each step. Averages hide the slow tail, and tail latency decides how many workers you need.
4. Count successes by content, checking that each response has the fields you parse.
5. Note what happens at the limit. A clean 429 with a reset time is easy to handle. Timeouts and dropped connections are not.
6. Price the run using the provider's billing rules, including whether failures were charged.

PrismCrawl's free 100 credits cover a functional test, and the SERP API playground shows the response format before you write any code.

PrismCrawl at scale

PrismCrawl sells one-time prepaid credit packages, and every package includes the same endpoints and SERP features. Every search runs live, one successful search uses one credit, and failed requests are free, so retries never inflate your bill. PrismCrawl's success rate is above 99%.

These are default limits. Custom plans run at 1,000 or more requests per second, which is at least 3.6 million searches an hour or 86 million a day. To set one up, email [email protected] with your expected monthly volume and peak requests per second. Credits are valid for 90 days, and the same balance covers Google, Bing, DuckDuckGo, Amazon, Maps, reviews, and app store endpoints, so one integration can serve several workloads. See SERP API pricing for current packages, or estimate your volume with the SERP API cost calculator.

How to choose a scalable SERP API

1. Work out your peak rate as well as your monthly volume. Divide the searches in your largest batch by the time window it must finish in.
2. Decide whether results can be queued. If they can, DataForSEO's standard queue is worth pricing. If a user or agent is waiting, compare live throughput only.
3. Check how the limit is tied to price. On SerpApi and SearchApi, a faster job means a bigger monthly plan. On PrismCrawl and Serper, the limit comes with the package and can be raised for larger accounts; PrismCrawl's custom plans start at 1,000 requests per second.
4. Price your real volume, including monthly resets, credit expiry, and whether failed requests are billed. The cheapest SERP API comparison covers prices from $10 to $1,000.
5. Load-test your shortlist with your own queries before signing a contract.

For a feature comparison beyond throughput, read the best Google SERP API buyer's guide. For provider-specific detail, see PrismCrawl vs. DataForSEO, PrismCrawl vs. SerpApi, and PrismCrawl vs. Bright Data.

Frequently asked questions

What is the most scalable SERP API?

It depends on whether the limit is speed or budget. Bright Data publishes no concurrency limit, Serper allows up to 300 queries per second on its $3,750 package, and Scrapingdog allows up to 2,200 concurrent requests on its largest monthly plan. PrismCrawl allows 100 requests per second by default on its $1,000 package, runs custom plans at 1,000 or more requests per second, and has the lowest cost at 10 million searches a month in this comparison: about $1,500 of usage at $0.15 per 1,000.

How many searches per hour can PrismCrawl handle?

The default limit on PrismCrawl's $1,000 Volume package is 100 requests per second, which is 360,000 searches an hour or about 8.6 million a day. Smaller packages start at 5 requests per second. Custom plans run at 1,000 or more requests per second, which is at least 3.6 million searches an hour; contact [email protected] to set one up.

Can SERP API rate limits be raised?

Usually, yes. PrismCrawl offers custom plans at 1,000 or more requests per second, Serper and DataForSEO raise limits on request, Oxylabs and Scrapingdog offer custom plans, and SerpApi directs custom throughput requests to its sales team. SerpApi and SearchApi tie hourly throughput to the size of the monthly plan, so faster collection on those services generally means buying a larger plan.

Do SERP APIs charge for failed requests?

PrismCrawl, SerpApi, SearchApi, and Bright Data bill only successful searches, and Oxylabs does not bill requests that fail with a server-side error. At high volume this matters because retries on a provider that bills failures raise the effective price per successful search.