Amazon Athena System Tables: Query History, Costs and Auditing

Amazon Athena now records completed query activity in service-managed system tables that teams can query with SQL. AWS publicly announced the feature on November 9, 2026, and its service release notes list November 6. The first table, query_executions, helps operators analyze query performance, failures and data scanned across workgroups in one account and Region. AWS announcement · Athena release notes

Original editorial illustration.

A team can investigate a single slow query with its execution ID. The harder question is whether that slowdown reflects a pattern across a workgroup, whether failures started after a deployment, or whether one workload is responsible for much of the data scanned. Previously, teams that wanted that history together often collected query metadata themselves and loaded it into a separate dataset. System tables give them a managed starting point for that analysis.

What does Athena put in the system table?

Athena is a managed SQL query service. When the feature is enabled, the service writes query metadata to read-only Apache Iceberg tables on Amazon S3 Tables. AWS manages schema, partitioning, compaction and snapshots. A completed query generates a row after it reaches a final state, including successful, failed and canceled executions. Data can take minutes to arrive. Queued and running queries do not have rows yet. System table documentation · Query execution schema

The first table contains execution IDs, workgroup names, timestamps, user identity, state, runtime measures and data scanned. It also has sensitive fields, including SQL text and submitted parameter values. A report on failures or scanned bytes rarely needs raw statements. Give readers a filtered aggregate or governed access where feasible.

Athena query execution history.

How does this compare with the existing monitoring tools?

Need	Existing path	What system tables add
Investigate a specific run	Call GetQueryExecution using the ID	Join finished runs with the rest of the history
Detect an operational change	Use CloudWatch metrics and alarms	Analyze historical distributions by workgroup or final state
Audit management actions	Use CloudTrail according to your audit policy	Analyze completed query activity and principals with SQL
Maintain query history	Export metadata to a dataset you operate	Athena manages collection and the Iceberg tables
Track spending	Use billing reports and workgroup data	Analyze bytes scanned or other usage drivers by workload
Build cross-account reports	Collect or federate data across boundaries	The managed scope is one account and Region

Keep the API for in-flight debugging and CloudWatch for alerting. The system table is a complementary analytical surface. The read-only design and schema management simplify operation, but they do not remove the need for access policies and retention management.

How do you enable and query Athena system tables?

Open Administration → System tables in the Athena console, then enable the feature. The configuration applies to the account’s current and future workgroups in that Region. Integrate the S3 Tables bucket with the AWS Glue Data Catalog before querying. If already integrated in the same account and Region, AWS says that step does not need to be repeated. Give the configuration role and query role separate permissions. Confirm encryption requirements before enabling ingestion. AWS documents SSE-S3 as the default when a customer managed KMS key is not supplied. Enablement and IAM

After running a small test query, wait for a completed execution to appear. Start with one workgroup. Replace analytics-dev with a real workgroup name. The SQL examples were checked against AWS’s column reference and were not executed against an Athena account.

SELECT
  state_enum,
  count(*) AS executions,
  sum(coalesce(data_scanned_size, 0)) AS bytes_scanned,
  approx_percentile(total_execution_duration, 0.95) AS p95_ms
FROM "s3tablescatalog/aws-athena"."metadata"."query_executions"
WHERE work_group_name = 'analytics-dev'
  AND submission_date_time >= current_timestamp - INTERVAL '7' DAY
GROUP BY state_enum
ORDER BY executions DESC;

The output groups final executions by state. Bytes scanned can indicate where to investigate data layout, partition filtering, or query changes. It is not the amount on an AWS bill. Capacity pricing, reuse, regional rates and service-specific billing rules can change the relationship between bytes and spend. Use billing records for financial reconciliation.

SELECT query_execution_id, completion_date_time, total_execution_duration
FROM "s3tablescatalog/aws-athena"."metadata"."query_executions"
WHERE work_group_name = 'analytics-dev'
  AND state_enum = 'FAILED'
  AND completion_date_time >= current_timestamp - INTERVAL '1' DAY
ORDER BY completion_date_time DESC
LIMIT 20;

The second query produces recent failures without exposing SQL strings or parameters. Use an execution ID to inspect an individual run when you have permission. If a row is missing, check whether the query finished, whether collection was active, and whether you are querying the correct Region and catalog. If access is denied, check the query role and any applicable Lake Formation governance. For an application perspective on SQL workloads, see ASP.NET Core CRUD with EF Core and SQL Server.

What are the retention, cost and Region constraints?

The launch covers Regions where Athena and Amazon S3 Tables are both available. AWS does not charge for delivery into the tables. Standard S3 Tables storage and maintenance charges apply, and querying the records incurs standard query costs for the engine you use. AWS does not set a default retention period, so configure record expiration in S3 Tables to match policy and budget. Filtering by workgroup can help partition pruning. Keep reporting queries selective, particularly if a dashboard refreshes frequently. Billing and limitations

Disablement stops new publishing without removing previously retained rows. Re-enabling does not backfill the gap. Keep separate retention plans for compliance records that already depend on CloudTrail or another archive. For a first evaluation, enable a development account and compare the resulting history with known successful and failed executions before designing production reporting.

How should a platform team use the first week of query history?

Pick one workgroup with a known mix of scheduled and interactive queries. Reconcile a handful of system-table records against their execution IDs from the console. Check completion times and outcome, then compare scan volume over a stable time window. Keep small workgroups in separate reports or show the number of observations next to a percentile. One unusual execution can dominate a small sample.

Before sharing a dashboard, decide which reports need identities and which only need aggregate counts. A team that reviews performance can often work with workgroup, query state, elapsed time and scan size. Keep access to raw SQL and parameters limited to authorized operators. If a retention policy or dashboard refresh cadence changes, rerun the same baseline query and confirm the change did not remove the history needed for the intended review.

Frequently asked questions

Can Athena system tables show running queries?

No. The first table records final executions after delivery. Use the Athena API or console for in-flight status.

Can you read the data outside Athena?

AWS stores it in Apache Iceberg format. Compatible engines can query it when catalog integration and access permissions permit. Examples in the announcement include DuckDB, Amazon Redshift and Amazon EMR.

Are system tables a replacement for billing reports?

They show usage and performance drivers such as bytes scanned and execution duration. Billing reports remain the source for actual billed costs.