← All platforms

AI readiness · Amazon Redshift

Redshift AI readiness assessment

Score your Amazon Redshift estate against the six factors that decide whether data is ready for an AI workload — read-only, metadata only, never a row of your data. Free to run.

Redshift estates tend to carry history. Many began as a migration from an older warehouse and accumulated the structures that migration produces: wide tables built for a specific report, staging schemas that outlived their pipeline, and naming conventions from a team that has since reorganised. None of that prevents an AI workload. It does decide how much of the estate is safe to point one at.

Redshift exposes its catalog through the SVV system views, which describe tables, columns, types, and policy objects without touching row data. The important structural detail is that those views are permission-scoped: they only show objects the querying user can access.

The Redshift readiness tension: visibility — the catalog itself is permission-scoped, so what a scan can see depends on what it was granted.

What the assessment reads on Redshift

• SVV system views — tables, columns, and data types across the schemas in scope.
• Declared constraints — primary and foreign keys, which determine whether entities and relationships are resolvable.
• Documentation coverage — table and column descriptions, which decide whether a corpus is interpretable by anything other than its author.
• Policy objects — masking and row-level security, where the querying user is permitted to read the relevant SVV views.

Those signals roll up into the six factors — Clean, Contextual, Consumable, Current, Correlated, Compliant — scored against roughly 50 requirements for the specific AI workload you pick, whether that is retrieval, agents, model training, or feature serving. The output is a readiness score, the single biggest blocker, and a prioritised fix plan with the score gain each fix earns. See the methodology for how scoring works.

Access it needs

A read-only user with USAGE on the schemas in scope and SELECT on their tables. As on Postgres, the SELECT grant is what makes the catalog visible — Redshift's SVV views only show objects the user can access — and the assessment still never issues a SELECT against your tables. Works for both provisioned clusters and Redshift Serverless.

CREATE USER mortariq_reader PASSWORD '<strong-password>';
GRANT USAGE ON SCHEMA <schema> TO mortariq_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA <schema> TO mortariq_reader;

The exact SQL each connector runs is published and generated from source, so a security review is a verification rather than a trust fall. If your warehouse cannot accept connections from the internet, the CLI agent runs the same metadata-only assessment inside your network. Full setup steps live in the connection guide.

The honest limits on Redshift

• If the user cannot read the SVV policy views, the masking and row-level-security checks report not assessable. That is the honest degrade, not an error.
• The endpoint must be reachable. For Serverless that means enabling public access on the workgroup and opening TCP 5439, and if the cluster must stay private, the CLI agent runs the same assessment inside your VPC instead.

A metadata scan cannot verify values anywhere: a comment can be stale, a constraint can be worked around in application code, and a fresh-looking table can be full of duplicates. What it gives you is the structural truth of the estate — what exists, what is documented, what is governed, what is fresh, and what your chosen workload requires that is missing. It prepares evidence. It does not certify compliance, and no tool that reads only metadata honestly can.

Also covers: Redshift Serverless, provisioned Redshift clusters.

Frequently asked questions

Want to see the output before connecting anything? Read a sample readiness report built entirely from metadata. Other platforms: see all six.