Job market intelligence is a data-math business — the team that collects the most postings per dollar wins the demo. This is a worked cost model for a 2-million-postings-per-month workload, priced three ways: raw residential proxies, per-result scraper APIs, and a hybrid. Along the way, a fair comparison of Thordata and Bright Data, because those were the two quotes on the table.

Labor market analytics products — wage benchmarks, hiring-signal feeds, skills-demand indices — all make the same promise: more postings, fresher, cheaper. The demo that wins is the one with the coverage chart. So when a recruitment analytics team sat down to rebuild their collection layer, they turned it into an arithmetic problem before touching any infrastructure.

The Workload, Specified Honestly

Every cost model is only as good as its workload spec. Here’s the one they used:

Parameter	Value
Target postings per month	2,000,000
Sources	Major job boards, company career pages, aggregators
Average posting page weight (HTML + assets)	~350 KB
Refresh policy	Daily for hot boards, weekly for career pages
Parse-and-dedup overhead	~30% of fetched pages are re-fetches of changed postings

Two implications fall out of the spec immediately. First, raw volume: 2M postings plus refresh overhead means roughly 2.6M page fetches per month, or about 900 GB of traffic if fetched as full pages. Second, a large share of the target sources are structured job boards — exactly the kind of standardized target that pre-built scrapers exist for. Keep that second fact in mind; it’s where the model gets interesting.

Route A: Raw Residential Proxies

The classic architecture: residential proxy traffic plus your own parsers. Priced with both vendors’ published rates:

	Thordata	Bright Data
Published entry rate	$2.00/GB at 1 GB	$8.00/GB pay-as-you-go
Rate at ~1 TB/month volume	$0.73/GB at the 1 TB slider point	$5.00–6.00/GB plan region ($999–$1,999/month plans); custom above 1 TB
900 GB/month, published prices	≈ $650–900	≈ $4,500–5,400
Minimum commitment	1 GB	Plans from $499/month (141 GB); PAYG available

At published prices, the same 900 GB costs roughly 5–7× more on Bright Data’s listed rates than on Thordata’s slider. To be fair about what that premium buys: Bright Data is one of the most complete enterprise web-data platforms in the industry — a vast IP network, mature unlocking products, enterprise compliance tooling, and a first-deposit match of up to $500 — and large buyers negotiate below list. If your organization needs enterprise agreements and an established enterprise vendor posture, those are real considerations. For a self-serve analytics team comparing published prices, though, the spread at this volume is the headline number.

But Route A has a deeper problem than the per-GB rate, and it applies to both vendors: job postings are heavy pages, and per-GB pricing taxes weight, not value. You pay to download the nav bars, the footer, the tracking scripts. Which raises the question the team asked next.

Route B: Per-Result Scraping

Thordata’s Web Scraper API bills per delivered result — about $1.00 per 1,000 results at entry volume, roughly $0.50 at scale — with 120+ pre-built scrapers including the major job boards, CAPTCHA solving and JavaScript rendering included. The same workload re-priced:

Metric	Value
Postings needed	2,000,000/month
Cost at entry rate ($1.00/1K)	$2,000/month
Cost at volume rate (~$0.50/1K)	~$1,000/month
Traffic concerns (blocked pages, retries, CAPTCHAs)	Billed upstream; failed attempts cost nothing

The comparison with Route A is not close. At ~900 GB, Thordata’s residential slider already beats per-result pricing’s entry rate — but the per-result model at volume (~$1,000 for the full workload) beats both, because it prices the deliverable instead of the download. And the operational surface shrinks too: no parsers to maintain when a board redesigns, no CAPTCHA logic, no retry budget.

Bright Data’s equivalent self-serve scraper products are priced through its platform plans; for teams already in that ecosystem they’re a legitimate path, but the published PAYG economics for this specific workload favor per-result pricing at scale.

Route C: The Hybrid That Actually Shipped

The team’s final architecture uses per-result scraping for the major boards, and keeps a raw residential layer for the long tail of company career pages — smaller sites with idiosyncratic layouts that no pre-built scraper covers:

Layer	Workload	Pricing	Monthly cost
Pre-built scrapers	1.6M postings from major boards	~$0.50/1K results	~$800
Residential proxies	~150 GB for career pages	Slider, ~$1.00/GB region	~$150
Career-page parser maintenance	~40 site templates	Engineering time	Declining

Total collection cost: roughly $950/month for 2 million postings — about $0.0005 per posting. The “how many postings can $1,000 buy” answer, for this workload, is two million.

The Layer Nobody Budgets: Search-Side Hiring Signal

The team’s product roadmap included a feature their clients kept requesting: which companies are visibly hiring — job ads running in search results, employer branding keywords, careers pages gaining search visibility. That signal lives in SERPs, not postings pages.

Adding it was a third pricing layer: Thordata’s SERP API at roughly $0.70 per 1,000 structured responses at volume, or the fully managed SERP monitoring solution for scheduled tracking. Monitoring the top 50,000 employer keywords daily prices out at roughly $1,000/month on top of the postings pipeline — and the continuous SERP data crawling service delivers it structured, so it feeds the same warehouse as the postings data with zero parser work.

FAQ

Why not datacenter proxies for the career pages? They’re cheaper. Career pages are small sites with crude rate limits, and datacenter IP ranges are the first thing small hosts block. A blocked career page in a residential-grade flow costs a retry; in a datacenter flow it costs a missing company in the coverage chart. The residential layer for the long tail is about reliability per dollar, not raw price per GB.

What about postings that disappear mid-refresh? Per-result pricing means expired postings that return “gone” are cheap signals rather than wasted traffic — a tombstone is a data point in labor analytics (the role was filled), and the collection cost model handles it naturally.

Isn’t 2M postings overkill for a mid-market product? Coverage is the product. The demo chart with 40% board coverage loses to the one with 85%, and per-result pricing is what makes 85% affordable — the marginal cost of a new board is its posting volume times $0.0005, known in advance.

How does this compare to just buying a job-postings dataset? Pre-built datasets (Thordata’s run about $0.25 per 1,000 records across 100+ domains) are ideal for historical backfill and model training, while live collection serves the freshness-sensitive product. Most mature teams run both: dataset for the historical base, collection for the delta.

What’s the migration path from an existing per-GB setup? Mirror a slice of traffic through the per-result API first — free trial credits cover it — and compare delivered postings per dollar on your own sources. The team in this story cut collection costs by roughly 60% versus their previous per-GB architecture without changing coverage, and the SERP monitoring layer followed the same try-before-commit pattern.

The generalizable lesson: in data-math businesses, the pricing model is the architecture decision. Per-GB pricing optimizes for traffic you control; per-result pricing optimizes for data you deliver. Job market intelligence delivers postings — so the team that prices per posting wins the coverage chart, and $1,000 buys two million of them.