AI readiness · PostgreSQL
PostgreSQL AI readiness assessment
Score your PostgreSQL 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.
Postgres usually is not a warehouse. It is the database underneath the application, and it arrives at the AI conversation from a different direction: nobody chose it for analytics, and nobody modelled it for a retrieval corpus. It was the right database for the product, and then someone pointed an agent at it.
That origin explains the whole readiness profile. A warehouse was built to be described. Postgres was built to be served. Its catalog is superb at structural truth, because the query planner depends on it, and nearly silent on everything a governance layer would add.
The PostgreSQL readiness tension: description — the database was never asked to explain itself to anything but the application.
What the assessment reads on PostgreSQL
- information_schema.columns and .tables — structure, types, and which columns were left as semi-structured blobs.
- pg_description — column comments — the single most revealing number in a Postgres assessment, and usually the lowest.
- information_schema.table_constraints — which tables declare primary and foreign keys, and which are joined by convention and tribal memory.
- pg_index and pg_tables — partitioning and secondary indexes, which decide whether retrieval is an operation or an outage.
- pg_policies — row-level security coverage — a genuine Postgres strength the warehouses reached late.
- pgvector columns — which tables already hold embeddings, and therefore where the retrieval corpus sits relative to the raw data.
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 dedicated read-only role with CONNECT on the database, USAGE on the schemas in scope, and SELECT on their tables. The SELECT grant is unavoidable on Postgres and worth understanding: Postgres only exposes catalog metadata for objects a role is permitted to see, so without it the scan reports an empty estate rather than an honest one. The grant makes the catalog visible; the assessment still never issues a SELECT against your tables.
CREATE ROLE mortariq_reader LOGIN PASSWORD '<strong-password>';
GRANT CONNECT ON DATABASE <db> TO mortariq_reader;
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 PostgreSQL
- Core Postgres has no column-masking catalog, so that requirement reports not assessable and returns an inventory of PII-candidate columns instead — identified by naming patterns, which makes them candidates rather than findings.
- There is no lineage in core Postgres. Anything claiming otherwise is inferring, not reading.
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: Amazon RDS, Aurora, Cloud SQL, Azure Database for PostgreSQL, Neon, Supabase, Railway, Heroku.
Frequently asked questions
What access does an AI readiness scan need on PostgreSQL?
A dedicated read-only role with CONNECT on the database, USAGE on the schemas in scope, and SELECT on their tables. The SELECT grant is required because Postgres only exposes catalog metadata for objects a role can see — without it the scan would report an empty estate. The grant makes the catalog visible; the assessment still never issues a SELECT against your tables.
Can the scan check whether PII is masked in Postgres?
Not on core Postgres, and it says so rather than guessing. Postgres has no native column-masking catalog the way Snowflake or Databricks does, so that requirement reports not assessable and returns an inventory of PII-candidate columns instead. Row-level security is the exception and is genuinely measurable through pg_policies.
Does this work with RDS, Aurora, Cloud SQL, Neon, and Supabase?
Yes — self-hosted Postgres and the managed flavors: Amazon RDS and Aurora, Cloud SQL, Azure Database for PostgreSQL, Neon, Supabase, Railway, and Heroku. On Supabase, connect with the Session pooler string rather than the direct db.<ref>.supabase.co hostname, which is IPv6-only and unreachable from most cloud platforms.
Get your readiness score.
Connect read-only credentials and see your score and biggest blocker in minutes. Metadata only. Starts free.
Run the free scanWant to see the output before connecting anything? Read a sample readiness report built entirely from metadata. For the deeper technical walkthrough, read the PostgreSQL assessment post. Other platforms: see all six.