Comparison
Bright Data vs Apify: Do You Need Records or a Workflow?
Bright Data's Scraper APIs bill per record; Apify bills Actor events and compute. Here's how to tell which fits your output and workflow.
I would choose Bright Data Scraper APIs when a supported target/schema matches the records needed, and Apify when the selected Actor plus schedules, queues and storage is the actual requirement. Bright Data Unlocker is a different raw-request product, so “Bright Data versus Apify” is not one interchangeable price comparison. Scraper product, Unlocker, Apify Store, schedules.
The useful question is what produces and maintains your validated output. One page may yield many records or none, while Apify compute and creator events measure different work; I would not award a cheapest platform from a request, record and CU table. Record pricing, compute, Actor billing.
Short on time?
Here's my take
- If you need prebuilt records
- Inspect Bright Data Scraper APIs
- Match the target/schema and record bill, without implying arbitrary Actor portability.
- If you need an Actor workflow
- Inspect Apify
- Events, resources, queues, schedules and permissions belong in the decision.
- If you only need a raw page
- Compare the narrower endpoint
- A transport requirement may not justify either full platform choice.
Prices verified . Sponsors cannot buy a verdict or a position.
What does each one actually deliver? #
The table compares outputs and workflow responsibilities; it identifies the buying boundary rather than a matched-output or performance result. Prices and specifications verified: 2026-11-11.
| Requirement | Bright Data product fit to inspect | Apify fit to inspect | What must still be verified |
|---|---|---|---|
| Supported extracted records | Scraper APIs | Selected Actor output | Actual fields, target, duplicates and fresh records |
| Raw known-page delivery | Unlocker | Selected fetch/crawl Actor | HTML/envelope versus entity output |
| Custom recurring job | Do not infer arbitrary Actor-code equivalence | Actor plus schedules | Input, timing, retries and job state |
| Retained outputs/work queue | Define the selected product delivery contract | Datasets and request queues | Retention, export, resume and operations |
| Budget | Request/record product and applicable fees | Events plus compute/proxy/storage | Actual charged unit and validated result count |
Sources: Unlocker, Scraper APIs, Apify Store, datasets, queues.
Does Bright Data bill records or requests? #
Scraper APIs bill extracted records, not an assumed one-request/one-page unit. The advertised Free allowance is 5,000 records monthly, PAYG $1.50 per 1,000 records, and Scale $499/384,000 records plus $1.30 per 1,000 additional records. Prices verified: 2026-11-11. Product, pricing.
I would inspect the actual supported target, schema and delivery needs before choosing it. A prebuilt record service does not automatically reproduce arbitrary Creator Actor logic, all job scheduling or every supported input/output contract.
Unlocker instead advertises 5,000 monthly free requests and $1.50 per 1,000 successful PAYG requests. Its raw HTML/JSON envelope delivery is not extracted entities or click control; browser interaction is a separate requirement rather than a hidden feature of that raw response. Unlocker pricing, introduction. If you do need clicks, the browser product bills differently; see Bright Data Browser API pricing.
I did not verify whether product free allowances are shared or stack, and I would not combine them into a larger advertised grant. Actual accepted-record counts and target eligibility also remain unmeasured.
What goes into an Apify Actor bill? #
Apify Free has $5 monthly usage; Starter $19, Scale $199 and Business $999 include their fee as prepaid usage, with enabled overage subject to limits. CU rates are $0.20 Free/Starter, $0.16 Scale and $0.13 Business, but resources are only part of a selected Actor’s bill. Pricing, subscriptions.
A CU is allocated one GB of memory for an hour, not completed records or peak-memory sampling. Proxy, transfer and storage can add costs, and an Actor’s event price may include platform usage or add it separately. Compute, Store billing.
| Actor model | Documented billing distinction | What I would inspect |
|---|---|---|
| Pay-per-event | Creator-defined result/start/other events; often platform included, sometimes additional | Event names/rates and inclusion |
| Pay-per-usage | No Creator surcharge, still platform resources | Runtime, memory, proxy, transfer and storage |
| Rental (retired) | Apify says unmigrated rental Actors switched to pay-per-usage on October 1, 2026 | The selected Actor’s actual current mode |
Store documentation, pricing, migration post.
I would not add generic proxy/compute fees twice when the selected event price already includes them. Conversely, an event max-charge rule is not proof that every separate resource line is inside the same ceiling.
Rental is gone from the current docs. Apify’s migration post set an October 1, 2026 sunset, and today’s pricing and Store pages describe only event and usage models; I did not check every listing, so inspect the selected Actor before quoting a recurring invoice. Migration post, pricing, Store docs.
Sometimes the workflow and permissions decide it #
Apify schedules, datasets and request queues are concrete reasons to compare the workflow rather than only scraping. I would preserve recurring launch rules, resume/deduplication state and retained output/export costs when replacing an Actor. Schedules, datasets, queues.
Permissions and Creator terms differ from generic platform access. Creators can access input/output, and full-permission Actors can reach broader account resources with approval normally required; maintained Actors are not automatically open-source, and community Actors are not a guaranteed result. Permissions, platform terms, Actor terms.
I would minimize secrets and approve only the needed scope, then establish code/data rights before copying behavior into a replacement. A client or framework licence is not automatic permission to clone proprietary Actor code. If you plan to rebuild the job in your own code, Crawlee vs Scrapy compares two open-source frameworks for that rebuild.
So how do you compare the costs? #
Start with a validated distinct usable-record definition, then separately count requests, returned records, Creator events and resource usage. One fetch can return multiple entities, while billable output may fail freshness/schema checks; the normalized denominator cannot be guessed from a plan headline.
For a hypothetical compute-only Apify job, one GB for three hours is three CUs, $0.60 at $0.20/CU before other costs. That does not tell me whether the job produced three, 3,000 or any usable records, so I cannot divide it into a Bright Data price comparison without the actual workload. Compute definition, rates.
Likewise, $1.50 per 1,000 Scraper API records is a record-rate input, not one thousand calls with identical page count or guaranteed validation. I would retain the actual product unit and count separately. Scraper pricing.
Do you need a whole platform at all? #
If only fetching/extraction is missing, compare the narrower contract rather than automatically buying a platform. Zyte’s target-tier HTTP/browser and extraction rates depend on actual site/mode, with a $100 standard PAYG ceiling and commitment floors/ceilings. Zyte pricing, billing rules.
ZenRows offers selected Fetch/Extract/Batch/browser/proxy paths with monthly Free 5,000 and Build $19/45,000 credits. Bee’s $19/75,000 and ScraperAPI’s $49/100,000 are different credit bundles; none by itself replaces all Actor schedules/storage. ZenRows, Bee, ScraperAPI. My scraping API credits explainer shows how those bundles turn into requests once JavaScript and premium weights apply.
Firecrawl’s Free 1,000 monthly credits and Hobby $19/5,000 address another ingestion path rather than a general Actor-platform equivalent. I would define the intended output before comparing that allowance with records or CUs. Firecrawl pricing. If Firecrawl is your other candidate, Firecrawl vs Apify covers that pairing.
Those are alternatives to a named requirement, not filler competitors in an overall winner table. The job may still need application-owned queues, schedules, parser/schema logic and backups even when a provider performs fetching.
Bright Data or Apify: which would I pick? #
For matching prebuilt records, I would inspect Bright Data Scraper APIs. For selected custom/ready-made Actors with the surrounding workflow, Apify; for raw page delivery, I would compare Unlocker and other narrower endpoints without assuming structured entities or browser actions.
Before migration I would document input/output, queue/resume state, schedules, retention/export, retry rules, permissions and billing. This article supplies no account, performance or independent user-review proof that either provider is a universal winner.
The scraping API pillar connects product layers. Apify pricing explains resource/event floors, Apify alternatives covers workflow migration, Zyte API pricing shows target-tier limits, best web unblockers compares raw-delivery units, and build versus buy includes surrounding operations.
FAQ #
How does Bright Data’s Scraper API bill? #
Extracted records, rather than an assumed one request or one page. Match actual target/schema and validation needs. Pricing, product.
Does Bright Data Unlocker return structured data? #
Its raw HTML/JSON envelope delivery is not a guaranteed entity schema or click-control workflow. Introduction.
Can I compare Bright Data records with Apify compute units? #
Not without real workload inputs. CU measures allocated memory times runtime, while Creator events and other resources can change the bill. Usage, Store docs.
Can I take an Apify Actor’s code with me? #
No automatic right is established. Review Creator code and permission/contract scope rather than infer it from platform access. Actor terms, permissions.
Are Apify rental Actors gone for good? #
Apify’s migration post says rental pricing sunset on October 1, 2026, with unmigrated rental Actors switched to pay-per-usage; current pricing and Store docs describe only event and usage models. I did not check every listing, so inspect the selected Actor’s mode. Migration post, Store docs, pricing.
Sources
21 sources, accessed .
Official pricing, docs, changelogs and status pages 21
- Apify pricing
- Subscriptions
- Usage and resources
- Store billing
- Apify rental-to-pay-per-event migration
- Actor permissions
- Apify terms
- Actor terms
- Schedules
- Dataset
- Request queue
- Web Unlocker pricing
- Web Unlocker
- Scraper APIs
- Scraper pricing
- Zyte pricing
- Zyte API billing
- Zenrows monthly pricing
- ScrapingBee plans
- ScraperAPI plans
- Firecrawl pricing
