Athena
AWS's serverless SQL engine that queries data directly in S3 — no clusters to run, billed at $5 per terabyte scanned, which makes file format your real query optimizer.
What is Athena?
Amazon Athena runs standard SQL (Trino-based) directly against files in S3 — CSV, JSON, Parquet, ORC — with zero infrastructure. Point it at a bucket, define a table in the Glue catalog, query. There is no cluster to size, patch, or idle: you pay **30 monthly bills from teams with $3,000 ones.
Scanned bytes are everything
Athena charges for bytes read, not rows returned, so the optimization playbook is about reading less. Columnar formats: converting CSV to Parquet means a query touching 3 of 40 columns scans ~1/10th the data — same query, 90% cheaper and faster. Partitioning: laying out S3 keys by date (dt=2026-07-14/) lets WHERE dt = ... skip everything else; unpartitioned logs make every query a full-table scan. Compression stacks on top. A CSV-to-partitioned-Parquet migration routinely cuts cost 10–100× — no other database gives you two orders of magnitude for a file-format change.
Where Athena fits — and doesn’t
It’s the right tool for ad-hoc analytics on data already in S3: log investigation, data-lake exploration, scheduled reports. It’s the wrong tool for sub-second dashboards (cold queries take seconds), high-concurrency BI serving, or anything transactional — there are no indexes, no updates without Iceberg-style table formats layered on.
What people get wrong
- SELECT * on a data lake. The habit from row stores becomes a billable event at scale.
- Millions of tiny files: per-object S3 overhead dominates; compact small files before querying.
- Skipping partition projection — tables with thousands of partitions spend longer listing metadata than scanning data.
Primary source: Amazon Athena documentation — performance tuning
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.