# Amazon Athena

> Serverless SQL over S3, billed by the terabyte scanned

Amazon Athena is a serverless interactive query service that runs SQL directly against data in Amazon S3, with no infrastructure to provision and a bill computed from the data each query scans.

Website: https://aws.amazon.com/athena/

## Use it when

- Your data already sits in S3 and you want SQL answers without provisioning or operating anything.
- Query volume is spotty or unpredictable, so paying per terabyte scanned beats paying for an idle cluster.
- You are on AWS and want Glue, Lake Formation, and IAM to do the cataloging and access control you would otherwise build.
- You need full DML on Iceberg tables without running an engine of your own.

## Think twice when

- Queries run constantly at high volume; scan-based pricing grows with usage, and a fixed-size Trino cluster or reserved capacity can be cheaper.
- You need sub-second dashboards; Athena queues and cold-starts, so an OLAP engine like ClickHouse serves that shape better.
- Your lake is poorly partitioned or row-oriented; the bill follows bytes read, so layout problems become cost problems.
- You may need to leave AWS; the service, catalog, and governance are all AWS-specific, though the Trino-derived dialect eases an engine move.

## How it runs

Fully managed and serverless: point it at S3, define tables in Glue, and query. Capacity scales automatically; reserved DPU capacity is available for steady workloads, and Spark applications run under the same service. Federation reaches about 30 sources through Lambda connectors. Clients connect over JDBC, ODBC, the SDK, or the console.

## Details

### General

| Attribute | Value |
| --- | --- |
| License | Commercial |
| Deployment | Managed, Serverless |
| Workload | Interactive, Batch |
| Operational complexity | Low |
| Pricing | Subscription |
| Documentation | https://docs.aws.amazon.com/athena/ |

### Query Engines

| Attribute | Value |
| --- | --- |
| Engine shape | Serverless by default; capacity reservations in DPUs give dedicated processing that workgroups queue against |
| Non-lake sources | Around 33 Lambda-deployed connectors (Redshift, DynamoDB, DocumentDB, MySQL, Postgres, Oracle, SQL Server, Teradata, SAP HANA, Kafka, MSK, OpenSearch, Neptune, Timestream) and past AWS to BigQuery, Snowflake, Azure Synapse and GCS |
| Table formats | Parquet, ORC, Avro, JSON and CSV; Iceberg has full DML, while Hudi and Delta Lake are read-only |
| Catalog required | The Glue Data Catalog by default; an external Hive metastore works through a Lambda connector |
| SQL dialect | Trino-derived (engine v3) |
| Client access | JDBC and ODBC drivers, the SDK and API, and the console query editor |
| Concurrent users | Per-account DDL and DML quotas by default; queries on a capacity reservation escape the quota and queue instead, for up to ten hours |
| Acceleration | Query result reuse skips execution and the bytes scanned, opt-in per query for up to seven days; unavailable for federated catalogs, Lake Formation tables and anything with row or column filtering |
| Failure recovery | Nothing to configure: a failed query is yours to rerun; reserved capacity queues rather than fails when busy |
| Access control | IAM over the API, S3 and Glue, with Lake Formation adding row and column filtering; workgroups isolate access and cost |

## Capabilities

- [Query Engines](https://matca.io/capabilities/query-engine)

---

Source: https://matca.io/amazon-athena
Last updated: 2026-08-31T11:40:48.948Z