8 Best SQL Engines for Iceberg Analytics on AWS (2026)

Start with the table and its catalog

This shortlist is for U.S. data teams that want SQL analytics over Apache Iceberg tables in Amazon S3, using services available in U.S. AWS regions. The decision starts with an existing table and catalog: which engine can read the current snapshot correctly, and which changes may it make?

That is a narrower question than choosing a general warehouse or replacing ClickHouse. Keeping tables in open storage can make several engines useful, but format versions, delete files, credentials, and catalog behavior still determine interoperability. These eight options address that shared job through different operating and billing models.

How we chose these engines

We reviewed current official product, Iceberg, catalog, region, and pricing documentation on October 27, 2026. Selection favors commercial services that can query S3 Iceberg data and offer a practical route for U.S. customers. Inclusion does not imply a U.S. headquarters, equal feature maturity, or identical read/write support.

We did not run comparative benchmarks or purchase infrastructure. Best-fit labels reflect documented capabilities and editorial judgment. USD figures identify the selected region, meter, and billing basis where verified; they are not equivalent all-in configurations. Storage, catalog operations, networking, and optional acceleration can add costs.

The eight engines at a glance

Pricing checked October 27, 2026. Match the catalog and table features first, then price the actual workload.

1. Firebolt — best overall editorial pick for read-focused analytics

Firebolt reads Iceberg v1/v2 Parquet tables directly on S3 and can mount an external catalog as a database. AWS Glue and REST catalogs are documented options. Metadata/data caching and partition pruning make it a useful first evaluation for repeated analytical reads, with managed regions in Northern Virginia and Oregon.

Keep its write boundary clear: Iceberg writes are export-only, without DML or time travel. Iceberg v3 deletion vectors are unsupported, and S3 Tables catalog support is labeled a Nightly Feature. A workload requiring updates in place needs a different write path.

Standard U.S. Small compute-optimized compute is US$0.92 per node-hour, billed per second. This is a compute example, not a complete lake query bill; include storage and AWS access costs. Test freshness settings and cold reads with the actual files.

2. Amazon Athena — best for AWS-native serverless lake queries

Athena supports reads, writes, DDL, and time travel over Iceberg, making it useful when an S3 lake needs SQL without a conventional warehouse cluster. Its documented path uses the AWS Glue catalog, Glue optimistic locking, and Iceberg v2 tables. U.S. endpoints include Virginia, Ohio, California, and Oregon.

The SQL pricing example is US$5 per TB scanned, with S3 requests/storage and Glue charges additional; capacity pricing is also available. Partition and column selection therefore matter to the bill.

Validate table features and writer coordination before enabling modifications. Athena warns that using another locking implementation can break transactions. Shared storage still requires a consistent commit mechanism.

3. Starburst Galaxy — best for managed SQL across catalog choices

Galaxy reads and writes S3 Iceberg tables using Glue, Hive, or its own metastore. Its documentation covers versions 1–3, time travel, and copy-on-write or merge-on-read updates. That suits teams wanting managed Trino-based SQL across lake sources.

Pro costs US$0.50 per credit in AWS Virginia, Ohio, and Oregon. One worker consumes six credits per hour, so the quoted credit price is not a complete cluster-hour price; worker count and additional services affect consumption.

Confirm catalog-specific maturity and connectivity. The Polaris REST connector remains public preview, and cross-region querying has separate qualifications. Select a catalog and region combination that supports the intended production workflow.

4. Dremio Cloud — best for catalog flexibility and lake operations

Dremio Cloud connects to multiple Iceberg catalogs, with Glue and REST connectors supporting reads and writes. Its U.S. AWS regions include Northern Virginia, Ohio, and Oregon. It fits teams seeking lake queries while keeping data in an open table format.

Pay-as-you-go compute costs US$0.20 per DCU. Consumption depends on engine size and running replicas, measured in seconds with a 60-second minimum; storage and networking can add charges.

Check the specific connector's capabilities and permissions. A read/write label for Glue does not make every catalog writable. Iceberg v2 remains the default, and an upgrade to v3 cannot be reversed to v2, so test compatibility across every engine sharing those tables.

5. Snowflake — best for warehouse SQL with external-catalog writes

Snowflake queries existing Parquet-backed Iceberg tables in S3 through catalog integrations. Catalog-linked databases discover remote tables, and compatible REST catalogs support reads and writes, including the AWS Glue REST endpoint. Commercial U.S. AWS regions include Virginia, Ohio, and Oregon.

Versions 1, 2, and 3 are supported, but row-level equality deletes are not. Customer-managed S3 storage has no Snowflake Fail-safe. Confirm the compatible REST configuration; an older Glue integration is a different path.

Billing includes warehouse compute credits, cloud services, and applicable refresh charges. Warehouse provisioning has a one-minute minimum, then per-second billing. A configured USD rate was not verified, so price the selected edition and region.

6. Databricks SQL — best for governed read-only foreign-table access

Databricks can read foreign Iceberg tables in S3 through catalog federation while applying Unity Catalog governance. This fits existing Databricks users adding lake data to SQL analytics. U.S. AWS deployments are documented, but Glue/Hive Iceberg federation remains labeled Public Preview.

Foreign Iceberg access is read-only. Parquet-backed versions 1–3 are supported, with important limits: v2 position/equality deletes, foreign partition evolution, and branches beyond main are unsupported.

SQL compute is metered in DBUs; a configured warehouse USD rate was not verified. Confirm the federation route, permissions, and required catalog storage root. Governance integration alone does not establish full compatibility with the writer that produced the source table.

7. ClickHouse Cloud — best for lake reads alongside native analytics

ClickHouse Cloud's DataLakeCatalog connects to AWS Glue and Iceberg REST catalogs without duplicating the source tables. Current engine documentation covers partition pruning, snapshot-based time travel, and position/equality deletes. This fits teams combining open lake data with native ClickHouse analytics.

Verify the deployed Cloud release and table features. Documented Iceberg v3 deletion-vector support is read-only, without v3 ALTER UPDATE or DELETE support. Version support should not be treated as permission to perform every mutation.

In AWS Northern Virginia, Scale compute lists US$0.2985 per compute-unit-hour, metered per minute. One unit is 8 GiB RAM and two vCPUs. Storage and transfer are separate; compare the complete service configuration.

8. Amazon Redshift — best for joining lake and warehouse tables

Redshift queries Glue-cataloged Iceberg tables and joins them with local warehouse data, using external schemas or auto-mounted catalogs. Current documentation lists versions 1–3 with feature-specific restrictions. It fits existing Redshift teams that want lake access within their warehouse workflow.

Iceberg time travel is currently unsupported. Keep metadata and data-file permissions aligned, and verify the exact features needed rather than assuming unrestricted writing from format-version support.

Pricing varies by deployment. RA3/DC2 use Spectrum, whose Virginia examples charge US$5 per TB scanned plus cluster costs. RG and Serverless use their own compute without a separate data-lake query charge; Serverless bills RPU-hours. U.S. regions are documented.

How to choose an engine for the same lake

Begin with a compatibility inventory: catalog type, S3 region, Iceberg version, data-file format, delete files, schema changes, and writers. Separate permission to read a table from permission to commit changes. If two engines will write, verify their catalog and transaction requirements before granting access.

Use a representative test table containing the actual mutation history, not only append-only samples. Compare results for deleted rows, evolved columns, and newly committed snapshots. Include cold queries and repeated queries at the same freshness tolerance; caching can change both response time and resource use.

Finally, run a realistic query schedule through each billing model. Count idle compute, worker replicas, scanned bytes, metadata operations, storage, and transfer. The practical choice is the service that reads the required tables correctly and meets the workload's operating budget, with explicit ownership of maintenance and recovery.