Explore SQL schemas and declarations

Analyze declarations, without connecting

Explorer reads indexed SQL source files. It does not ask for a database password, open a database connection, execute queries or apply migrations. Its graph describes declared structure and source relationships, not the current contents or effective schema of a running server.

Open a SQL source

1. Choose API & DB, then Database schemas, in the indexed workspace.

2. Find the SQL source and open it. Check the source identity and current revision.

3. Start with automatic dialect detection. If the source is unknown or ambiguous, select PostgreSQL, MySQL or SQLite explicitly for that source.

4. Inspect Tables, Indexes and Declarations. Open the source evidence for the item that matters.

5. Use Table graph for declared structure, or Tables + code to inspect supported linked code. Read uncertainty notices before following a relationship.

Supported declaration detail

• Tables and columns: names, types, declared nullability, primary/unique/foreign keys and bounded defaults.

• Indexes: supported simple index declarations, source column order and explicit ASC/DESC where present.

• PostgreSQL identity columns, quoted identifier case, and bounded function/procedure/trigger declaration headers.

• Recognized ALTER TABLE actions such as add, drop, rename, default and nullability changes, retained as declarations with their own source evidence.

• CHECK expressions, routine bodies and unmodeled options remain explicit opaque or partial content; capturing text does not evaluate it.

Automatic dialect selection

Automatic detection starts with recognizable SQL syntax. When supported source evidence proves how a migration is invoked, Explorer can also show a context-derived dialect. A directory name or driver dependency alone is insufficient. Portable SQL can remain unknown, and conflicting evidence can be ambiguous. An explicit selection does not certify the syntax or the live database. Read the detection evidence and incomplete-reading notices.

Relationships between migrations

CREATE and ALTER declarations can be shown with possible target relationships. A unique scoped candidate is still a static candidate. Repeated names, separate schemas, missing scope, temporary tables or incomplete input can leave several candidates or no resolved target. File order alone does not establish execution order or a final applied schema.

Limits by database family

• PostgreSQL: supported source names are normalized according to quoted/unquoted identifier rules; runtime search paths, overload resolution and applied migrations are not inferred.

• MySQL: bounded table/index declarations; dynamic SQL and unsupported compound bodies stay partial.

• SQLite: bounded declarations; runtime pragmas, database contents and trigger execution are not inspected.

• This guide does not claim SQL Server/T-SQL, Oracle PL/SQL, MongoDB or a universal database connector.

Follow a table into code

Open Database uses in code or the table’s code action. A source declaration and a code reference are separate observations. Read the database-code guide before treating a name match as the same table.

Agent query

Ask a connected agent to read the exact SQL source with get_db_schema, report its dialect, columns, keys and completeness, and cite ranges. Never ask it to convert an unresolved match into a verified live table.