Amazon 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.