What a 1 Million Tweet Dataset Actually Costs in 2026: Every Route Priced

TL;DR: A million tweets costs $40.00 through a metered search API at $0.0008 per call and 20 tweets per call, both figures measured rather than quoted. The same million costs $250.00 on the cheapest scraper that publishes a per-unit rate, $0 plus a licence problem from an academic archive, and an unknown four-figure sum from a dataset vendor that will not print a number. The spread is not the interesting part. The interesting part is that nine of the ten pages ranking for this question do not answer it at all.

Search for the cost of a tweet dataset and you get ten results from ten different domains. Exactly one puts a price in its title.

That is a strange thing for a commercial query. The person typing it has a number in mind, usually because someone upstream asked what the data will cost. They get back a list of vendors, three "every way to collect Twitter data" comparisons that compare routes without costing any of them, and two forum threads where researchers ask each other the same question and receive recommendations instead of arithmetic.

This post fixes the quantity and does the arithmetic.

The rule this post follows about its own numbers

Every figure below carries a tag, because a price you cannot trace is a rumour with a dollar sign in front of it.

MEASURED means we read it from the system that emits it, or observed it directly. DERIVED means we computed it from measured inputs, and the computation is shown. PUBLISHED means a third party states it publicly and we link it. UNKNOWN means nobody will say, and we write unknown rather than guessing.

That last category is not padding. Two of the routes below genuinely refuse to publish a number, and the honest output for those is a blank, not an estimate dressed up as research.

The quantity: one million tweets

Comparisons go vague because they never pick a volume. "Per call" and "per record" and "per month" cannot be compared until you fix the amount, so we fix it at one million tweets and hold it constant across every route.

A million is a useful size. It is large enough that per-unit pricing dominates any setup cost, small enough to be a real project rather than a research grant, and it is roughly what a sentiment model, a brand-monitoring backfill, or a year of one mid-size account's mentions actually needs.

Route 1: a metered search API

$40.00 for a million tweets. DERIVED from two measured inputs.

Here is the derivation, in full, because a number without one is not evidence.

The first input is the per-call price. It is $0.0008 for tweet/advanced_search. That figure is MEASURED: it comes out of the biller's own endpoint-costs.json, the file the billing system reads at charge time, not from a pricing page that may have drifted from it.

The second input is how many tweets one call returns. The published API reference says "roughly 20 tweets per call". Roughly is not good enough to build a cost model on, so we ran one:

{
  "query": "\"machine learning\" lang:en",
  "product": "Latest",
  "count": 20,
  "tweets": [ /* 20 items */ ],
  "has_more": true,
  "next_cursor": "DAADDAABCgABHRDtt1dbsQUKAAIdEOjMSRbgVAAIAAIAAAACCAADAAAAAAgA"
}

Twenty. MEASURED, one live call, 2026-08-31.

So:

1,000,000 tweets / 20 tweets per call = 50,000 calls
50,000 calls x $0.0008 per call       = $40.00

Where this number is soft, stated plainly. Page size is documented as "roughly" 20 and we observed 20 on a single call. One observation is not a distribution. If real-world pages average 18 rather than 20, the same million costs $44.44, and if some queries return short pages near the end of a result set, the true figure drifts up rather than down. Treat $40.00 as a floor that holds when pages come back full, not as a guaranteed invoice.

A useful cross-check: the public pricing page states $0.00004 per tweet. Multiply by a million and you get $40.00, and $0.0008 / 20 = $0.00004 exactly. Two surfaces that were derived independently agree, which is weak evidence they are both right and strong evidence neither has silently drifted from the biller.

The platform's own framing of the shift is worth reading, because it explains the pricing model the rest of this post prices against:

https://x.com/XDevelopers/status/2019881223666233717

Pay-per-use is the reason a per-call figure is even a meaningful unit here. Under the old tier model the question was which bracket you fell into; under metering it is arithmetic, which is what makes the comparison below possible at all.

Route 2: a scraper marketplace

$250.00 for a million tweets. PUBLISHED by the vendor, in its own page title.

The cheapest scraper actor that publishes a per-unit rate advertises $0.25 per 1000 Tweets directly in the title that ranks. That is refreshingly legible, and it is the only price visible anywhere in the top ten.

1,000,000 / 1,000 = 1,000 units
1,000 units x $0.25 = $250.00

6.25 times the metered API for the same million. Both numbers are real and public, and the comparison is fair on price alone.

Where it is not fair, and this cuts against us as much as for us: a marketplace actor is a different product. You are buying someone else's maintained scraper plus the platform's orchestration, retries and storage. If your alternative to paying $250 is writing and maintaining that yourself, the $210 gap buys back real engineering time. Price is one axis. It is simply the axis the query asked about, and the one nine of ten results decline to discuss.

Route 3: a dataset vendor

UNKNOWN. Two of the ten ranking results sell datasets and neither publishes a per-record price.

Position 1 advertises "over 31.1M+ records available". Position 4 offers "20M records". Neither states what a record costs, or what a million of them costs. Both route to a sales conversation.

We are not going to invent a number for this. The honest output is UNKNOWN, and it is worth being precise about what that means: not "expensive", not "probably four figures", not a range we reverse-engineered from a competitor's blog. Nobody will say, so we write unknown.

What we can say factually is structural. A fixed dataset and a metered API answer different questions. A dataset is a snapshot someone else chose the boundaries of, which is exactly right when you want a defined historical corpus and exactly wrong when you want the last six hours. A metered call is the reverse. Comparing their prices without saying which shape you need is the mistake that makes most of these comparisons useless.

When a platform reprices its API, the third-party layer built on it does not adapt, it closes. The clearest public record of that dynamic is the Apollo shutdown, where a developer published the call transcripts and the arithmetic rather than the usual vague statement:

https://www.reddit.com/r/apolloapp/comments/144f6xm/apollo_will_close_down_on_june_30th_reddits/

It is worth reading before you build a business on any single data route, whichever platform you are on. The lesson is not "platforms are hostile", it is that a route with one supplier and no published price is a route whose cost you do not control.

For the mechanics of getting credentialed on the official path, this walkthrough is current as of 2026 and covers the console steps that change most often:

https://www.youtube.com/watch?v=aZz9D0FdevA

Route 4: public archives and academic dumps

$0.00 in money. NOT free in the ways that end projects.

Two of the ten results are archives: a Kaggle dataset of roughly 144,000 tweets, and a forum thread pointing at a complete day of Twitter, about 375 million tweets.

The money cost is genuinely zero. Three other costs are not.

Licence. Academic tweet corpora are typically distributed as ID lists rather than tweet text, precisely because redistributing content violates platform terms. Turning IDs back into tweets is called hydration, and it is a second data-acquisition project bolted onto the first, priced per call like any other.

Decay. Hydration only returns tweets that still exist. Deleted, suspended and protected accounts return nothing. The older the corpus, the larger the hole, and the hole is not random: deleted content correlates with exactly the controversial material many research projects are studying.

Boundaries you did not choose. A dataset built for someone else's research question carries their sampling decisions. If those do not match yours, the price of the data was zero and the price of discovering that was your timeline.

An archive is the right answer when you need a defined historical corpus, you can live with hydration gaps, and your licence position is sound. It is the wrong answer when you need completeness or recency, and it is the wrong answer more often than its price suggests.

Route 5: the official platform API

PUBLISHED elsewhere, NOT VERIFIED HERE. We are not printing a number we did not read from the source.

This is the route readers ask about most and it is the one we are least willing to guess at. X's access tiers have been repriced repeatedly, tier names and quotas have moved, and several of the comparison posts ranking for this query cite figures old enough to be wrong.

So rather than copy a number from a competitor's 2025 comparison and present it as current, we state the method: read the tier table on the platform's own developer pricing page at the moment you are budgeting, then divide your monthly tweet cap into a million to find how many months of a tier a million tweets actually takes. That last step is the one people skip, and it is where official-API budgets go wrong, because the binding constraint is usually the monthly cap rather than the sticker price.

If a comparison post quotes you an official-API price without a retrieval date beside it, treat the number as unverified regardless of how confident the prose sounds. That applies to this post too, which is why the row below says what it says.

Every route, one table, one million tweets

Route	Cost for 1M tweets	Provenance	Best when
Metered search API	$40.00	DERIVED from two MEASURED inputs	You need recency, control of the query, or an ongoing pull
Scraper marketplace	$250.00	PUBLISHED in the vendor's own title	You want someone else to maintain the scraper
Dataset vendor	UNKNOWN	No public per-record price	You need a defined historical corpus and can run procurement
Public archive	$0.00 plus hydration	PUBLISHED, free to download	Research, licence position sound, gaps acceptable
Official platform API	NOT VERIFIED HERE	Repriced repeatedly, read it live	You need first-party terms and can live with monthly caps

Two of five rows do not contain a price. That is not a gap in the research. It is the finding: this market does not publish its prices, which is precisely why the query exists and why the pages answering it are so thin.

The volume sensitivity nobody mentions

The ranking flips with quantity, and none of the comparisons say so.

At a million tweets the metered API wins by 6.25x. Run the same arithmetic at other volumes and the picture changes shape:

        10,000 tweets:     500 calls x $0.0008 =   $0.40   vs   $2.50
     1,000,000 tweets:  50,000 calls x $0.0008 =  $40.00   vs $250.00
    50,000,000 tweets: 2.5M calls  x $0.0008 = $2,000.00   vs $12,500.00

The ratio is constant because both are linear, which is the actual insight: neither route has volume breakpoints, so a pilot's unit economics are the same as production's. That is unusual and it is useful. It means a $4 test at 100,000 tweets tells you exactly what the million will cost, with no surprise cliff at scale.

Where the linearity breaks is the dataset vendor, whose whole commercial model is a large fixed price for a large fixed corpus. Below some volume they are absurd, above some volume they may be the cheapest thing available. Without a published number, neither you nor we can locate that crossover, and a comparison that pretends to is guessing.

Four costs that never appear in anyone's pricing table

The sticker price is the part everyone compares. These are the parts that actually decide the invoice.

Overfetch. You pay per call, not per useful tweet. A query that returns 20 tweets of which 3 match your real filter costs the same as one that returns 20 keepers. Tightening the query upstream, with language filters, engagement floors and date bounds, is the single largest lever on total spend, and it costs nothing to pull.

Pagination waste at the tail. The last page of a result set is rarely full. On a query returning 1,050 tweets you pay for 53 calls and receive an average page well under 20 near the end. At a million tweets across many queries this is a real single-digit percentage, and it is the main reason we called $40.00 a floor rather than an invoice.

Retries and transport failures. Any live API returns errors sometimes. We hit a 502 while researching this post, on the very endpoint we were pricing. Whether a failed call bills is a question worth asking any vendor directly, and worth asking before you sign rather than after.

Storage and egress. A million tweets with full metadata is not a small object. The cost of holding and moving it is frequently larger than the cost of acquiring it, and it appears in nobody's comparison because it lands on a different team's budget.

Why this query is answered so badly

We looked at all ten ranking results, and the pattern is consistent enough to state as a finding.

Ten results, ten distinct domains. No incumbent owns this query, which is unusual for a commercial term and tells you the demand is real while the supply of good answers is not.

Three are vendors who cannot answer neutrally, and two of the three decline to publish a price at all.

Three are editorial comparisons that list routes without costing any of them. They are not lazy; they are structurally unable to give a number, because they never fix a quantity. "Per call versus per record versus per month" has no answer until someone picks a volume, and picking one is the entire job.

Two are forum threads where researchers ask this exact question and receive tool recommendations rather than arithmetic.

One is a dataset that ranks for the phrase while answering a different question, and one is a link list.

So the query says cost, and the SERP mostly returns catalogue. The reason is not that the answer is hard. It is that answering it requires publishing your own price next to a competitor's, fixing a quantity that makes you look worse at some volumes, and writing UNKNOWN where you could not find out. Vendors will not do the first, comparisons will not do the second, and almost nobody does the third.

A million of what, exactly

Every route above sells you "tweets" and they do not mean the same thing. This is the comparison under the price comparison, and it is missing from all ten ranking results.

A tweet as an object can be almost anything between two extremes. At the thin end: an ID, a timestamp, and some text. At the thick end: the text plus author profile, follower and following counts at capture time, engagement counters, the reply and quote graph, language detection, attached media URLs, and the conversation root.

The gap between those matters commercially, because the thin version frequently cannot answer your question at any volume.

Three worked cases.

Sentiment over time. Text and timestamp are enough. Almost any route works, and you should buy on price. This is the one case where the cheapest option is straightforwardly correct.

Influence or reach weighting. You need author follower counts as they were when the tweet was posted. Archives generally cannot give you this: they were captured with the counts of that moment, and if you hydrate them today you get today's counts attached to yesterday's tweets. That is not a smaller dataset, it is a wrong one, and nothing about the price warned you. A live metered pull captures both together.

Conversation structure. Replies, quotes and the thread root are separate objects. If your route returns tweets but not the graph, reconstructing it means more calls, so your effective per-tweet cost rises by whatever the traversal costs. Price the traversal, not the tweet.

So the honest unit is not cost per tweet. It is cost per tweet that answers your question, and a route at a third of the price with two thirds of the fields you need is not cheaper.

The one question to ask any vendor first

Before comparing prices, ask what a single record contains, and ask for one.

Not a schema, not a docs page. An actual record from an actual call, which every route above can produce in under a minute. Then check it for the two or three fields your analysis genuinely depends on.

This inverts the usual order, and the inversion is the point. Most buyers pick on price and discover the field gap during integration, at which point the switching cost is a rewrite. Checking first costs one API call and a few minutes of reading.

The reason we can be specific about the metered route's shape throughout this post is that we made that call, printed the response, and counted what came back. That is also the reason the dataset-vendor row says UNKNOWN: we could not make the equivalent call without entering a sales process, which is itself information about what buying from them will be like.

What we would want a competitor to point out

Two things, in the interest of not writing an advertisement.

The $40.00 assumes our page size holds across your queries. It is one observation on one broad query. Narrow queries with heavy filters end in partial pages sooner, and every partial page bills as a full call. We have said this three times in this post because it is the single figure most likely to be quoted without its caveat.

A metered API is not the right shape for every job. If you want one defined historical corpus, delivered once, with a licence you can show a legal team, a dataset vendor is a better product than a pay-per-call endpoint, and the fact that they will not publish a price does not make them wrong. It makes them harder to compare, which is a different complaint.

The claim we will defend is narrower than "cheapest": for a fixed million tweets, with recency, with query control, and with a price you can verify before you spend, the arithmetic above is reproducible by anyone in about a minute. Every number in it names where it came from, and the two we could not source say UNKNOWN instead of guessing.

That is a low bar. It is also, on the evidence of this SERP, one that nine of ten ranking pages do not clear.

Pricing your own query before you spend anything

The arithmetic above is generic. Yours will differ, and you can find out for a few cents rather than by reasoning about it.

Run one call, count what comes back, then multiply. That is the whole method, and it is the one step that turns a budget from an argument into a measurement.

import os, requests

r = requests.get(
    "https://api.twitterapis.com/twitter/tweet/advanced_search",
    headers={"x-api-key": os.environ["TWITTERAPIS_KEY"]},
    params={"query": '"machine learning" lang:en', "queryType": "Latest"},
    timeout=30,
)
r.raise_for_status()
page = r.json()

per_call = len(page["tweets"])
target = 1_000_000
calls = -(-target // per_call)          # ceiling division, partial pages still bill

print(f"tweets per call   : {per_call}")
print(f"calls for {target:,}: {calls:,}")
print(f"cost at $0.0008   : ${calls * 0.0008:,.2f}")
print(f"more pages?       : {page['has_more']}")

Two details that matter more than they look.

Ceiling division, not floor. A partial page bills as a call. Rounding down understates every estimate, and it is the most common error in home-made cost models.

Measure on your real query, not ours. A narrow query with heavy filters returns short pages sooner and costs more per useful tweet than this example suggests. The number you want is the one your filters produce.

For a genuinely honest figure, run it across several representative queries and take the mean page size rather than trusting one observation, which is the same caveat we applied to our own $40.00.

Deciding without re-reading any of this

You need the last N days, or an ongoing pull. Metered API. Archives are stale by construction, and a dataset vendor's snapshot has a cut date.

You need a defined historical corpus and have procurement. Talk to the dataset vendors, and make a published per-record price a condition of the conversation.

You are doing research, your licence position is sound, and gaps are acceptable. Start with the archives. Budget the hydration pass as its own metered project rather than discovering it later.

You want someone else to own scraper maintenance. The marketplace route at $250 per million is buying engineering time, not data. Whether that is expensive depends entirely on what your engineers cost.

You do not know your volume yet. Run the snippet above. Neither metered route has volume breakpoints, so a $4 test at 100,000 tweets predicts the million exactly.

Before committing to any monitoring product, it is worth knowing what a monitor should tell you when it is failing, because a dead collector and a quiet week produce the same empty inbox.

FAQ

How much does a million tweets cost? Between $0 and an unknown four-figure sum, depending on route. Through a metered search API at $0.0008 per call and 20 tweets per call it is $40.00. Through the cheapest scraper marketplace that publishes a rate it is $250.00. Public archives are free in money and cost you licence work, hydration and coverage gaps. Dataset vendors do not publish a per-record price.

Why do most comparisons not give a number? Because they never fix a quantity. Per-call, per-record and per-month pricing cannot be compared until you choose a volume, and choosing one makes the writer's preferred option look worse at some volumes. Fixing the quantity is the work.

Is the cheapest route the right route? Not usually. Price is one axis and the others are recency, completeness, licence position and who maintains the collector. A free archive that lacks the last six months is infinitely expensive for a project that needs them.

What is hydration and why does it cost money? Academic corpora usually ship tweet IDs rather than tweet text, because redistributing content violates platform terms. Hydration is turning those IDs back into tweets, which is itself a metered data-collection project. It also only returns content that still exists, so older corpora come back with holes.

Does a failed API call still bill? Ask your vendor directly and get the answer in writing before you commit. We hit a 502 on the very endpoint we were pricing while researching this post, so this is not hypothetical. It is also not something any pricing page we reviewed addresses.

Do I pay per tweet or per call? Per call, and the difference is the whole cost model. A call that returns 20 tweets and a call that returns 3 bill identically, so your real unit cost is set by how full your pages come back, which is set by how narrow your query is. Broad queries fill pages and look cheap per tweet; heavily filtered queries return short pages and cost more per useful record even though the per-call price never moved. Anyone quoting you a flat per-tweet figure has averaged away the variable that actually matters.

Why is $40.00 called a floor rather than a price? Because it assumes every page comes back full at 20 tweets. Real result sets end in partial pages, and heavily filtered queries hit short pages sooner. The direction of the error is always upward, so treat $40.00 as the best case and measure your own queries for the real one.

The verdict

A million tweets is $40.00 through a metered API, $250.00 through the cheapest scraper that will tell you its rate, $0.00 plus real licence and coverage work through public archives, and an unpublished number from a dataset vendor.

But the more useful takeaway is the one the SERP itself hands you. Ten pages rank for a question about cost and one of them contains a price. When an entire market answers a pricing question with a catalogue, the reason is rarely that the arithmetic is hard.

Fix your quantity. Run one call. Multiply. The whole exercise costs less than a cent and replaces every comparison you were about to read, including this one.