Use a Redshift materialized view when repeated analytics queries justify storing a refreshed, precomputed result. Use an Iceberg table when the data should remain a cataloged lake table that Redshift and other catalog-based workflows can access. They solve different problems, so you can also use both: query an Iceberg source and precompute a frequently needed result in a materialized view. The right design depends on freshness needs, refresh behavior, Iceberg version, deployment, and measured workload—not a universal speed or cost ranking.
What each option does
Redshift materialized view
A materialized view stores the result of a query. Repeated queries can read that precomputed data instead of recalculating the defining query each time. Its contents reflect the base relations only through the most recent refresh; changes to source data do not appear in the view until it is refreshed. AWS explains querying materialized views and their stored results.
Iceberg table
An Iceberg table is a data lake table format, rather than a saved result of a particular analytics query. Redshift can query Iceberg tables registered in the AWS Glue Data Catalog. The compute path depends on the Redshift deployment, and AWS recommends generating Glue column statistics for best performance. Redshift query results have transactional consistency for Iceberg tables, with the visible data following the table state committed and available to the query. See AWS’s Iceberg integration documentation.
Compare the options
| Decision | Redshift materialized view | Iceberg table |
|---|---|---|
| Primary role | Stores a query result for repeated use. | Stores data in an Iceberg lake-table format that Redshift can query through Glue Data Catalog. |
| Freshness | Shows data through its latest refresh; base-table changes are not reflected until then. | Queries see the committed Iceberg table state available to them; freshness follows table commits and visibility. |
| Ongoing work | Requires refreshes, which may be incremental or recompute the defining query. | Requires suitable table and catalog operations; Glue statistics are recommended for performance. |
| Interoperability | A Redshift database object; it can be built over external Iceberg data or, with supported configuration, stored as Iceberg. | A lake table in an open format, queried by Redshift through the catalog. |
| First question to ask | Do repeated queries recalculate enough work to justify maintaining a precomputed result? | Should this data remain available as a cataloged Iceberg table for Redshift and other lake workflows? |
When a materialized view is the better fit
Start with a materialized view when a known set of queries repeatedly computes the same useful result, the result can tolerate a defined refresh interval, and the cost of maintaining it is justified by measured workload benefits. This is a query-acceleration and precomputation choice, not a replacement for deciding where the underlying data belongs.
Free tools Windows power users keep installed
One-click scans. No signup required.
#1 Best Overall
- Identify the repeated query or query pattern and the data it reads.
- Set an acceptable freshness interval: consumers need to know how old the stored result may be.
- Confirm whether the view’s query and source changes support incremental refresh, or whether refresh will rerun the defining query.
- Measure query performance and refresh resource use together; a faster read is not enough if maintenance outweighs the benefit.
When an Iceberg table is the better fit
Choose Iceberg when the data should live as a lake table and be queried through the Glue Data Catalog, including by Redshift. This choice is about data representation, catalog access, and the deployment’s query path—not about storing one precomputed answer for a particular dashboard or report.
- Confirm the table is registered in Glue Data Catalog and the Redshift deployment can use the intended compute path.
- Generate Glue column statistics as AWS recommends for best performance.
- Include catalog and table maintenance in the operating plan, and test with the actual queries and data layout.
How refresh changes freshness and cost
Redshift can refresh a materialized view incrementally, applying qualifying source changes, or perform a full refresh that reruns the defining query and replaces the stored result. Eligibility depends on the query shape and source operations; some SQL constructs prevent incremental refresh, and operations such as VACUUM or TRUNCATE can trigger recomputation. AWS documents these behaviors in materialized-view refresh guidance and the REFRESH MATERIALIZED VIEW command reference.
Automatic refresh is scheduled as soon as possible after changes, but Redshift weighs workload activity and available resources and can delay it. If consumers need more predictable timing, use manual or scheduled refresh and set expectations around that schedule. The AWS refresh documentation notes a behavior change dated February 27, 2026: on provisioned clusters running CURRENT Track patch P198 or newer, Auto REFRESH runs as user queries; this behavior is currently disabled on Serverless. Check the deployment type and patch context before relying on that detail.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Using materialized views and Iceberg together
The choice is not strictly either-or. Redshift supports materialized views over external Iceberg tables, and it also supports materialized views stored in Iceberg format. The two patterns have different constraints, so verify the table version, query definition, and refresh requirements before adopting either.
Materialized view over an external Iceberg table
Refresh may fall back to full recomputation if required Iceberg snapshots have expired. AWS also documents a limit of up to 4 million positions deleted in a single data file before the base table must be compacted to continue refreshing. Concurrency scaling is not supported for creation and refresh in this external-table case. Query definitions and table changes can also require a full refresh. See AWS’s external data lake materialized-view limitations.
Materialized view stored as Iceberg
A materialized view can be created with USING ICEBERG, subject to the constraints in the CREATE MATERIALIZED VIEW reference. The documented form requires source tables to be Iceberg format v2 or lower and in the same AWS Region and account as the materialized view. Auto refresh is not supported for this form, so refresh is manual.
Version support matters: AWS states that Redshift cannot create materialized views on Iceberg v3 tables. Check the current Iceberg v3 support documentation as well as the create-command requirements before designing a combined workflow.
Quick Recap
A practical way to choose
- Decide where the data belongs. If it needs to remain a cataloged Iceberg lake table, establish that as the data layer; a materialized view may still serve a repeated-query need above it.
- Define the freshness contract. Record how stale results may be, when refresh must complete, and whether automatic timing is adequate.
- Check refresh eligibility and maintenance. Determine whether incremental refresh is available for the query and source changes; account for full recomputations, snapshot retention, deletions, and compaction where applicable.
- Verify version and deployment. Check Iceberg version, Redshift deployment type, catalog configuration, and relevant patch behavior against AWS documentation for your environment.
- Benchmark the real workload. Compare query latency and resource use alongside refresh work, update cadence, catalog/statistics operations, and maintenance reliability. Do not assume either option is always faster or cheaper.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →
