SIXTA Precursor

48 health checks across 6 categories on your Supabase PostgreSQL database — covering security, indexes, query performance, schema design, configuration, and maintenance. Connect with one click via Supabase OAuth — no database credentials required.

What it does

SIXTA Precursor scans your database metadata and system catalogs to produce a scored health report with actionable findings. Each finding includes severity, an explanation of the risk, and a concrete recommendation (often with the exact DDL to fix it).

Security (18 checks)

Includes all Supabase advisor security lints:

• RLS disabled on public tables — tables exposed via the API without Row Level Security
• Auth users exposed — auth.users accessible through API views without security_invoker
• Sensitive columns exposed — columns like password, ssn, or credit_card in API-accessible tables without RLS
• RLS policy issues — policies referencing user-editable user_metadata, multiple permissive policies for the same role, RLS enabled but no policies defined
• Extension hygiene — outdated extension versions, unsupported reg* column types
• And more: unindexed foreign keys, materialized views in API schemas, auth function init plan checks

Index analysis (4 checks)

• Missing indexes — tables with high sequential scan ratios that would benefit from an index
• Unused indexes — indexes never used for scanning, wasting storage and slowing writes
• Duplicate and redundant indexes — exact duplicates or leading-column prefix overlaps
• Foreign keys without indexes — missing indexes on FK columns that cause slow JOINs and CASCADE operations

Query performance (8 checks)

Requires pg_stat_statements (gracefully skipped if not available):

• Slowest queries — top queries by total execution time
• High I/O queries — queries with poor cache hit ratios reading heavily from disk
• Temp file queries — queries spilling to disk due to insufficient work_mem
• Query plan analysis — detects sequential scans with filters on large tables, nested loop joins with inner seq scans, large sorts, and high-cost plans via EXPLAIN (GENERIC_PLAN, FORMAT JSON)
• Production-scale simulation — optionally recreates your schema on a separate database, injects your production table statistics (row counts, column distributions), and re-runs EXPLAIN to show how your queries would behave at full production scale. This catches problems that only appear with large tables. The simulation also tests suggested index fixes and shows before/after cost comparisons. Your database is never modified; the simulation runs entirely on a separate PostgreSQL instance.

Configuration (7 checks)

• PostgreSQL settings review — checks shared_buffers, work_mem, effective_cache_size, max_connections, and other key tuning parameters against recommended values
• Connection utilization — current active, idle, and idle-in-transaction connections as a percentage of max_connections

Schema (3 checks)

• Missing primary keys — tables without a primary key
• Large unindexed tables — tables over 1 MB with zero indexes
• Table bloat — estimated dead space from UPDATE/DELETE churn

Maintenance (8 checks)

• Dead tuple ratio — tables with high ratios of dead-to-live tuples needing vacuum
• Vacuum and analyze recency — tables that haven't been vacuumed or analyzed recently
• Transaction ID wraparound risk — tables approaching the TXID wraparound threshold
• Long-running transactions — active or idle-in-transaction sessions holding resources
• Index bloat — B-tree indexes with significant wasted space

Prerequisites

• A Supabase project (any plan)
• Recommended: The pg_stat_statements extension enabled for query performance checks. You can enable it from the Supabase Dashboard under Database → Extensions, or by running:

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

Without pg_stat_statements, query performance checks are skipped. All other categories (security, indexes, schema, configuration, maintenance) work without it.

How it works

SIXTA Precursor connects to your Supabase project through the Supabase Management API using OAuth 2.0. It never receives or stores your database password.

Once connected, Precursor executes read-only SQL queries against your database's system catalogs (pg_catalog, pg_stat_user_tables, pg_stat_statements, pg_settings, etc.) to collect diagnostic metadata. It does not read or modify your table data, schema, or configuration.

The analysis runs on demand. You initiate a scan, it runs, and you get results immediately. There is no continuous background process or persistent connection to your database. No results are stored server-side — once the page is closed, the data is gone.

Connect your Supabase project

1. Go to SIXTA Precursor
2. Click Login with Supabase
3. You'll be redirected to Supabase to log in (if needed) and authorize SIXTA Precursor
4. Select the project you want to analyze
5. Optionally enable Simulate production-scale query plans to test how your queries would perform at larger data volumes
6. Click Scan Selected Project to start the analysis

Results are displayed immediately as an HTML report with a composite health score, findings grouped by category, and recommended fixes.

Alternative connection methods

You can also connect directly without OAuth by providing either:

• A PostgreSQL connection URI (e.g., postgresql://postgres:password@db.xxx.supabase.co:5432/postgres)
• A Supabase Project ID and database password

These methods give Precursor a direct PostgreSQL connection to your database. Credentials are used only for the duration of the scan and are not stored.

What SIXTA Precursor accesses

Precursor reads only system catalogs and metadata — never your table data:

Precursor does NOT access:

• Your table data (no SELECT on user tables)
• Authentication tables or user credentials
• Supabase Storage files
• Edge Function code or logs
• Billing or account information

Revoking access

You can disconnect SIXTA Precursor at any time:

1. Go to your Supabase Organization Settings
2. Navigate to the OAuth Apps tab
3. Find SIXTA Precursor and click Revoke

Once revoked, SIXTA Precursor can no longer access your project. Since no analysis data is stored server-side, there is nothing to delete.

Troubleshooting

"pg_stat_statements not found"

The extension isn't enabled on your project. Enable it from the Supabase Dashboard under Database → Extensions, search for pg_stat_statements, and toggle it on. It may take a few minutes for query statistics to accumulate after enabling. Query performance checks will be skipped, but all other checks will still run.

"No queries found"

If pg_stat_statements was just enabled, it needs time to collect data. Run some queries against your database and try again in a few minutes.

"Authorization failed"

Your OAuth token may have expired. Click Login with Supabase to re-authorize. If the issue persists, revoke access in your Supabase organization settings and connect again.

"Token exchange failed"

This usually means the OAuth app configuration has changed. Try clearing your browser cookies for the Precursor site and logging in again.

"Scan is slow"

The Supabase Management API has rate limits (120 requests/minute). A typical scan uses around 20 API calls and completes in 15–45 seconds. Scans with the simulation option enabled may take longer (up to 2 minutes) as additional queries are needed to extract schema metadata.

Data handling

• No analysis data is stored server-side. Results are rendered directly in your browser and are not persisted. Closing the page discards the results.
• No table data is ever read, transmitted, or stored — only system catalog metadata.
• OAuth tokens are held in an encrypted session cookie for the duration of your browser session (up to 24 hours). They are not stored in any database.
• You can revoke access from Supabase at any time, immediately invalidating all tokens.

Support

If you have questions or run into issues, contact us at support@sixta.ai.