Amazon Athena
Serverless SQL over files in S3. You pay for bytes scanned, not for hours running.
Reach for it when
- Your data already lives in S3 and you want to query it in SQL without loading it anywhere.
- Usage is bursty or irregular: a few dozen queries a day, long idle gaps, nothing to keep warm.
- You read open formats (Parquet, ORC, Iceberg) that other engines, Spark, Redshift Spectrum, DuckDB, also need to read.
- You need a cheap query endpoint for BI tools, notebooks and ad-hoc investigation on logs, exports and data-lake tables.
Think twice when
- You need sub-second dashboards for many concurrent users. Athena's latency floor is seconds, and heavy concurrency queues.
- The same large tables are scanned again and again: per-byte pricing punishes repetition, and a warehouse or a compacted, columnar copy ends up cheaper.
- Your data is a swamp of small files. Thousands of tiny objects make every query slow and expensive before a single row is filtered.
What it actually is
Amazon Athena is a query engine, not a database. It runs SQL against files you already have in S3 and returns the result, then walks away: it stores nothing, keeps no cluster warm and holds no copy of your data. Under the hood it runs a managed fork of Trino (Athena "engine version 3"), with an option to submit Spark code for the same data. Every result set is itself written back to an S3 bucket you own.
Because Athena has no storage of its own, the table definitions live elsewhere: in the AWS Glue Data Catalog. A "table" in Athena is a pointer, a schema plus an S3 location plus a file format, and the data is read as-is at query time. This is schema-on-read. Nothing is loaded, indexed or optimized for you when you create a table, which is why file layout (format, compression, partitioning, file size) decides most of the cost and speed of every query.
In a platform, Athena is the query layer of a data lake: the cheapest way to open S3 data to analysts, BI tools and notebooks. It reads the same Parquet and Iceberg tables that Spark on Glue or EMR write, and it can also reach into other sources, relational databases, DynamoDB, CloudWatch Logs, through federated connectors.
How it works
From a SQL statement to a result file in S3
- 01
Parse and plan
Athena resolves every table name against the Glue Data Catalog: schema, S3 location, format, partition keys. With Hive-style tables it lists the partitions that match your WHERE clause; with partition projection it computes them; with Iceberg it reads the table's own metadata.
- 02
Prune
Before reading any data, the engine drops what it can prove irrelevant: whole partitions outside the filter, then row groups whose min/max statistics exclude the predicate, and columns you did not select.
- 03
Scan, execute, write
Workers read the surviving byte ranges from S3 in parallel, filter, join and aggregate. This is the billed step. The result lands as a file in your query results bucket; nothing else is kept unless you asked for CTAS or INSERT INTO.
What it really costs
You pay per terabyte of data scanned from S3 (about $5 per TB in most regions, check the current price for yours), with a 10 MB minimum per query. DDL statements and failed queries are free; cancelled queries are billed for what they had already read. Provisioned Capacity replaces the per-scan meter with a fixed hourly price for dedicated compute, billed whether queries run or not.
- Uncompressed text formats. A SELECT on CSV or JSON scans every byte of every column, every time. The same data in compressed Parquet, where Athena reads only the columns you ask for and bills on the compressed size, routinely scans 10 to 50 times less.
- SELECT * and filters that miss the partition key. Columnar formats only save money if you name your columns, and partitions only save money if your WHERE clause hits the partition key. A dashboard filtering on event_time over a table partitioned by country scans the whole table.
- Small files. Ten thousand 100 KB objects cost more than one 1 GB file: each object is a separate S3 GET request and a separate unit of work, and Parquet statistics cannot prune inside files this small. The Athena line on the bill looks fine; the S3 request line does not.
- Repeated identical queries. A BI tool refreshing the same query every minute pays the full scan every minute, unless query result reuse is enabled on the workgroup or the result is materialized once with CTAS.
- Costs that land on other bills. Federated queries invoke Lambda; large Hive-partitioned tables generate Glue Data Catalog requests at planning time; results written to S3 accumulate storage unless a lifecycle rule deletes them.
The one-page Amazon Athena field guide.
Best practices, cost traps and performance checks, in the order you should run them. Printable, no fluff.
Articles
No articles on Amazon Athena yet — the first deep dive is on the way.