---
title: Amazon S3 Tables
description: S3 Tables are managed Apache Iceberg tables on S3 — purpose-built table buckets with auto-compaction, snapshot management, and up to 3× better query performance than self-managed Iceberg on standard S3.
url: https://www.factualminds.com/glossary/s3-tables/
publishDate: 2026-06-13
updateDate: 2026-06-13
---

# Amazon S3 Tables

> S3 Tables are managed Apache Iceberg tables on S3 — purpose-built table buckets with auto-compaction, snapshot management, and up to 3× better query performance than self-managed Iceberg on standard S3.

## Definition

Amazon **S3 Tables** provides **managed Apache Iceberg** tables stored in **table buckets** — a bucket type optimized for tabular data with AWS-operated maintenance: compaction, snapshot expiration, and orphan file cleanup. You get Iceberg's **ACID transactions**, schema evolution, hidden partitioning, and time travel without scheduling Glue Spark jobs to rewrite small files every night. S3 Tables reached **GA** at re:Invent 2024 and integrates with Athena, Amazon Redshift, EMR, Glue, and SageMaker Lakehouse through the AWS Glue Data Catalog or native table catalog APIs.

Compared to self-managed Iceberg on general-purpose S3, AWS claims materially higher write throughput and up to **3× faster selective queries** on maintained tables because background compaction keeps file layouts query-friendly. Pricing includes storage, requests, compaction processing, and per-object monitoring — offset maintenance labor and often query compute savings on large datasets.

| Aspect           | Self-managed Iceberg on S3 | S3 Tables                 |
| ---------------- | -------------------------- | ------------------------- |
| Compaction       | Your Spark/Glue jobs       | AWS-managed               |
| Snapshot cleanup | Your scripts               | Automatic policies        |
| Catalog          | Bring your own             | Native + Glue integration |
| Bucket type      | General purpose            | Table bucket only         |

## When to use it

- New **lakehouse** or medallion architectures (bronze/silver/gold) where Iceberg is already the table format choice.
- Teams tired of operating **compaction SLAs** and snapshot retention cron jobs on open-table formats.
- Multi-engine analytics — same Iceberg table queried from Athena, Redshift Spectrum, and Spark without duplicate copies.
- Streaming ingest landing in Iceberg with concurrent writers needing snapshot isolation.

## When not to use it

- Arbitrary binary objects, JSON logs, or media — use standard S3 buckets.
- Existing **Delta Lake** or **Hudi** estates without a migration program — format conversion has engineering cost.
- Ultra-low-latency keyed lookups — Iceberg is analytical; OLTP belongs in Aurora, DynamoDB, or RDS.

## Tips

- Configure **snapshot expiration** and orphan-file policies at table creation — default snapshot retention grows storage silently on high-churn pipelines.
- Use **table-level IAM grants** on table buckets instead of blanket bucket admin for data-mesh ownership boundaries.
- Register tables in **AWS Glue Data Catalog** once for cross-engine discovery — avoid duplicate metastores per team.
- Model **partition transforms** (day/month) in Iceberg hidden partitioning so analysts do not write brittle `WHERE year=...` paths.
- Benchmark **compaction costs vs query savings** on a representative partition before migrating petabyte-scale legacy Hive tables.

## Gotchas

- **Serious:** Placing non-tabular data in **table buckets** wastes specialized pricing and breaks tooling expectations — keep logs and assets in general-purpose buckets.
- **Serious:** **Concurrent writers** without Iceberg conflict handling can produce commit failures — implement retry semantics in streaming jobs.
- **Regular:** **Time travel queries** over long snapshot histories are expensive — cap retention to what auditors actually require.
- **Regular:** Cross-region analytics on table buckets needs explicit **replication design** — table buckets are regional.
- **Regular:** Engines cached old schemas after **schema evolution** until metadata refresh — automate `MSCK REPAIR` / catalog sync in pipelines.

## Official references

- [S3 Tables pricing](https://aws.amazon.com/s3/pricing/) — storage, requests, compaction, and monitoring meters.
- [Query S3 Tables with Athena](https://docs.aws.amazon.com/athena/latest/ug/querying-s3-tables.html) — SQL access patterns.

## Related FactualMinds content

- [Amazon S3](/glossary/amazon-s3/) — object storage foundation
- [AWS Data Analytics Services](/services/aws-data-analytics/)
- [Lakehouse on AWS Pattern](/patterns/lakehouse-on-aws/)

## Related AWS Services

- aws-data-analytics

---

*Source: https://www.factualminds.com/glossary/s3-tables/*