Amazon Athena

Amazon Athena runs SQL directly over files in S3 — there is no cluster to size and no data to load. It uses the AWS Glue Data Catalog for schema and bills by data scanned. AddisDB reaches it through the AWS SDK, authenticated by the ambient AWS credential chain, exactly as it does for DynamoDB and Timestream.

Who it is for

Athena suits ad-hoc analysis over data already sitting in S3 — logs, exports, data-lake tables in Parquet or Iceberg. Because you pay per byte scanned rather than per hour, it is well suited to occasional querying and poorly suited to dashboards that re-run the same broad scan every minute.

The cost model deserves a moment. Partition pruning and columnar formats are not tuning niceties here; they change the bill. A SELECT * over an unpartitioned dataset scans everything.

Set up access

1. Make sure your AWS credentials are already working — aws sts get-caller-identity should succeed. AddisDB reads the same chain (environment, shared config, SSO, IAM role) and stores nothing.
2. Note the region your Athena workgroup lives in.
3. Note the Glue database you want to browse, and the workgroup if it is not primary.
4. Confirm the workgroup has a query result location in S3. If it does not, you will need to supply one on the connection.

aws sts get-caller-identity
aws athena list-work-groups --region us-east-1

Connect from AddisDB

1. New Connection → Amazon Athena.
2. Put the AWS region in the host field — there is no hostname.
3. Put an AWS profile name in the username field, or leave it blank to use the default credential chain.
4. Put the Glue database in the database field, as database or database/workgroup.
5. If the workgroup has no result location, put an S3 staging path (s3://bucket/prefix/) in the connection string field.
6. Test, then Save. The password field is ignored.

What AddisDB gives you

Queries and the Big Data Console, plus the schema tree read from information_schema, exports and saved queries. Athena’s engine v3 is Trino underneath, so the SQL dialect is Trino’s.

Athena is asynchronous — a query is started, polled, then read. AddisDB does that for you and bounds the polling, so a query that runs long returns a clear message naming its execution id rather than hanging. You can then find that exact run in the Athena console.

A failed Athena query is reported by the API as a successful call with a FAILED state, and its results include a repeated header row. AddisDB checks the state before reading results and drops the duplicate header, so failures surface as errors and grids do not open with a row of column names.