JDBC

The JDBC adapter connects with read-only credentials and uses standard `DatabaseMetaData` calls plus dialect-specific extensions (PostgreSQL `information_schema`, SQL Server `sys.*`, Oracle `ALL_*` views, MySQL `information_schema`) to capture the live shape of the database.

Captured metadata includes tables, views, materialized views, columns with full type qualifiers (precision, scale, length), primary keys, foreign keys with referential actions, unique constraints, check constraints, indexes, and column-level statistics (row count estimate, null fraction, distinct count) when the dialect exposes them.

Connections never store credentials in the ledger. The connection profile is itself a versioned MetaModel asset whose secret material lives in the project's secret store; the ledger entry references the profile ULID, not the credentials. This is what keeps JDBC ingests defensible under HIPAA §164.312(a)(2)(iv) (encryption and decryption controls) and FedRAMP IA-5 (authenticator management).

Each scan writes a `SchemaIngested` entry with the importer module identifier (`JdbcImporter@x.y.z`), the connection profile ULID, the database product/version captured at scan time, and the SHA-256 of the canonicalized metadata payload. Re-running the same scan against an unchanged database produces a byte-identical hash.

Re-scans against a previously-ingested database write `SchemaEvolutionEvaluated` with a structured diff: added/removed/renamed tables, added/removed columns, type changes, and constraint changes. The diff classification feeds the same draft/publish workflow as file-based ingests — there is no special path for live databases.

JDBC ingest is the standard way to surface a production database into Magellan for Source‑to‑Target Mapping. Because the introspection result is hash-checked into the ledger, a reviewer can prove which physical schema state a mapping was authored against, even if the database has since been migrated.