--- title: "Firebolt vs Athena: Index or Scan" excerpt: "Why $5/TB looks cheap until the dashboard refresh rate multiplies the scan." authors: "Tinybird" categories: "AI Resources" createdOn: "2026-09-30 00:00:00" publishedOn: "2026-09-30 00:00:00" updatedOn: "2026-09-30 00:00:00" status: "published" --- Amazon Athena prices the query by bytes scanned. Firebolt prices the engine by the hour. Both can sit on object storage. The meters do not care that the SQL looks similar. AWS's on-demand SQL examples use **$5 per TB scanned**. Their own example: 3 TB uncompressed text, one query, **$15** ([Athena pricing](https://aws.amazon.com/athena/pricing/)). Queries round up to the nearest megabyte with a **10 MB minimum**. Refresh the same prefix 240 times an hour and you are not paying $5/TB once. You are paying it 240 times, minus whatever partition prune actually saved. Firebolt Standard US is **$0.23 per FBU-hour**. A compute-optimized Small is 4 FBU, **$0.92/hour** ([Firebolt billing](https://docs.firebolt.io/managed-service/billing)). `$0.92 × 24 × 30.4 ≈ $672/month` is arithmetic for one Small left on 24/7, not a list SKU. Storage is pass-through S3: **$27.07 per TiB/month** in us-east-1. Storage-optimized Small is a different node (8 FBU, $1.84/hour Standard US). [Druid vs Athena](https://www.tinybird.co/blog/druid-vs-athena) is the streaming-indexer-versus-scan argument. [ClickHouse® vs Amazon Athena](https://www.tinybird.co/blog/clickhouse-vs-amazon-athena) is the engine-level companion. This page is the warehouse-index-versus-scan argument: when $5/TB is the cheaper sentence, and when an engine (or a serving table) is cheaper because the refresh rate stopped multiplying bytes. ## The SQL is not the difference Firebolt documents [`DATE_TRUNC`](https://docs.firebolt.io/reference-sql/functions-reference/date-and-time/date-trunc). Athena (Trino lineage) uses `date_trunc`. Function names differ. The grain does not. ```sql -- Firebolt SELECT DATE_TRUNC('minute', ts), country, COUNT(*), SUM(revenue) FROM page_views WHERE ts >= NOW() - INTERVAL '1 hour' GROUP BY 1, 2 -- Athena SELECT date_trunc('minute', ts), country, COUNT(*), SUM(revenue) FROM page_views WHERE ts >= current_timestamp - INTERVAL '1' HOUR GROUP BY 1, 2 ``` In Firebolt that is pruned granules (and maybe an aggregating index) on a running engine. In Athena that is a priced scan of the hour prefix, if you partitioned well. Neither path is an HTTP API with a tenant token. Tinybird is the serving path for that case: ClickHouse SQL, Kafka or Events API, a pipe. ## Prefix prune is not a primary index Firebolt tablets keep min/max metadata so whole tablets drop out, then the primary index binary-searches granules (~8,192 rows default). `PRIMARY INDEX (country, ts)` makes `WHERE country = 'US' AND ts > ...` a range. `PRIMARY INDEX (ts)` with a filter only on `country` is a worse scan. Aggregating indexes are a second table keyed by the `GROUP BY`. The planner uses them when grouping keys match. You never name the index in the query. If it does not match, you scan the fact tablets. Athena layout is Hive / Iceberg partitions plus columnar files. `date=2026-09-30/hour=14/country=US` is the prune. Miss a partition column in the `WHERE` and you pay for a wider prefix at $5/TB. There is no sparse primary index. Compression and Parquet column projection are the cheap tricks. Iceberg time travel (`FOR SYSTEM_TIME AS OF`) is a lake feature Firebolt tablets do not pretend to be. Firebolt engines stay up until you stop them. Local SSD cache compensates for object storage. Warm aggregating indexes make the second query fast. You can run separate engines so BI concurrency does not collide. That is a usage pattern, not a product rule that one workbook equals one engine. Athena spins ephemeral workers. Each query can start cold. Metadata and some result cache exist. They do not turn Athena into an always-on serving layer. Federated connectors add Lambda. Fine for "join S3 to a JDBC source once." A 15-second product tile is a scan line item. ## Firehose is the freshness you forgot Athena ingest is files in a bucket. For Amazon S3 as the destination, Firehose buffering interval is **0 to 900 seconds**, default **300** ([Firehose buffering hints](https://docs.aws.amazon.com/firehose/latest/APIReference/API_BufferingHints.html)). S3 *backup* of another destination still uses 60 to 900 seconds. Tiny objects are a scan tax and a GET tax. Glue or Iceberg catalogs the layout. Partition projection keeps you from listing a million prefixes. `OPTIMIZE` on Iceberg is a job, not an index. Firebolt ingest is a SQL write on an engine: `COPY`, or Kafka via `CREATE STREAM` plus `READ_STREAM` ([CREATE STREAM](https://docs.firebolt.io/reference-sql/commands/data-definition/create-stream)). Offsets advance in the write transaction. The engine must be running for the `INSERT`. Freshness is "after the last successful commit." Athena freshness is "after the last object plus buffer." The older AWS path (Kinesis to S3 to Glue to Athena) is in [comparing Tinybird to Kinesis, S3, Glue, and Athena](https://www.tinybird.co/blog/comparing-tinybird-to-aws-kinesis-s3-glue-and-athena). ## One assumed 8 GB hour, three refresh rates These are **worked examples**, not vendor quotes. Assumed: after compaction the last hour is **8 GB** of Parquet (Athena) or the equivalent tablets (Firebolt). 12 hours/day, 22 days/month. Athena on-demand **$5/TB**. Firebolt compute-optimized Small **$0.92/hour** while running. Once an hour, internal. Athena: 8 GB × 12 × 22 = 2,112 GB ≈ 2.1 TB/month ≈ **$10.50**. Firebolt: start a Small, query, stop. Minutes of FBU. Athena still wins on dollars if you already have the files. Stop building an engine. Every 5 minutes, analyst dashboard. Athena: 8 GB × 12 refreshes/hour × 12 × 22 = 25,344 GB ≈ 25 TB/month ≈ **$124** if every refresh stays on the hour prefix. Firebolt: keep the Small up 12 hours. `$0.92 × 12 × 22 ≈ $243`. Athena can still be cheaper **if** the query never scans extra partitions. One missed filter and $124 becomes a different number. Every 15 seconds, customer tile. Athena: `8 GB × (3600/15) × 12 × 22` = **506,880 GB ≈ 495 TB/month × $5 ≈ $2,475/month for one tile**. Ten tiles with poor overlap is a 5-figure scan line before S3 GET charges. Firebolt: the Small cannot stop. **~$243/month** for that engine until concurrency forces a larger size. The index is why the refresh rate no longer multiplies bytes. Athena Capacity Reservations change the last formula. AWS's own example: 160 DPU × $0.30 × 0.25 h = **$12** to cover a 15-minute peak ([Athena pricing](https://aws.amazon.com/athena/pricing/)). You are now managing capacity, which was the thing Athena was supposed to avoid. If you refresh once an hour for an internal workbook, Athena wins. If you refresh every 15 seconds, an indexed engine (Firebolt, ClickHouse, Tinybird) is the cheaper sentence. If the data will never be indexed and queries are rare, Athena remains correct. ## Refresh the tile without rescanning the hour Athena assumes a workgroup and a human. Firebolt assumes an engine and a BI tool. Tinybird takes the same events and publishes the SQL as a pipe. Ingest does not wait for Firehose's default 300-second flush. The [Events API](https://www.tinybird.co/docs/forward/ingest-data/events-api) accepts JSON over HTTP (documented default: 100 requests per second per datasource; 10 MB per request on Free). The [Kafka connector](https://www.tinybird.co/docs/forward/ingest-data/connectors/kafka) reads the topic. `ORDER BY (country, ts)` is the sparse index. A materialized pipe is the aggregating index, in git. The app calls HTTP, not a workgroup: ```bash curl "https://api.tinybird.co/v0/pipes/hourly_tile.json?token=$TOKEN" ``` The pipe behind that URL is ordinary ClickHouse SQL. Point it at a rollup once you have one, so you are not scanning 8 GB of Parquet on every refresh: ```tinybird DESCRIPTION > Last-hour revenue by minute and country. NODE hourly_tile SQL > SELECT toStartOfMinute(ts) AS minute, country, count() AS events, sum(revenue) AS revenue FROM page_views WHERE ts >= now() - INTERVAL 1 HOUR GROUP BY minute, country ORDER BY minute, country TYPE ENDPOINT ``` `npx tinybird deploy` after `npx tinybird preview`. The 15-second tile that is **~$2,475/month** in the Athena on-demand worked example is a Developer plan plus vCPU overage at **$0.0002 per vCPU-second** once the rollup exists ([Tinybird pricing](https://www.tinybird.co/pricing)). Published Developer sizes include **S-2 at $199/month** and **S-4 at $399/month** ([Developer plan sizes](https://www.tinybird.co/blog/new-developer-plan-pricing)). The meter is compute on a small aggregated table, not $5/TB rescanned, and not a Small engine left on 24/7. You do not get Athena federated joins to a JDBC source, or Firebolt's isolated engines for BI. Wrong buy for a 1-hour internal workbook on files you refuse to index. Right buy when freshness must be seconds and the consumer is an app. ## Keep Athena for files you will never index Use Athena for the lake already in the account: audits, one-off joins, data that will not be indexed. Use Firebolt when BI concurrency needs isolated engines and someone will design the primary index. Use Tinybird when the same `GROUP BY` is a product API. ## Frequently Asked Questions (FAQs) ### Are Firebolt and Athena alternatives? No. Firebolt indexes tablets and answers from an engine. Athena scans objects in S3 at $5/TB. If the event is still only on a Kafka topic and you have not committed `READ_STREAM` or written an object, neither can answer. ### When is Athena cheaper than Firebolt? In the worked example above, an internal workbook that refreshes once an hour on an assumed 8 GB partitioned prefix is about $10.50/month on-demand. A customer tile that refreshes every 15 seconds on that same prefix is about $2,475/month per tile. Those dollars follow from $5/TB and the assumed 8 GB, not from a vendor quote for your table. Firebolt's engine-hour cost wins at high refresh rates if you keep a compute-optimized Small up. Athena wins at low query volume.