Microsoft SQL Server

One asset per table or view, never one per row. The asset carries the table's structure — database, schema, table name, object type, its columns and their types, and a row-count estimate — and its content is a sample of real rows, formatted so a detector reads actual values rather than a schema dump.

How many rows, and which ones, is entirely up to the sampling strategy. Large tables are paged through by key rather than by OFFSET, so a scan that stops halfway can resume from where it left off instead of re-reading from the top.

Read-only throughout. The connector issues catalog queries and bounded SELECTs. Nothing is written back, and a read-only account is the right account to give it.

Relationships come out of the engine's own catalog: foreign keys are recorded as REFERENCE links — useful, but they move no data, so they never become a lineage hop, and a view and the tables it reads from are recorded as FLOW — real lineage, with column-level detail parsed out of the view's SQL where the SQL makes that possible. See Lineage.

SQL Server exposes dependency metadata directly, which makes it one of the strongest lineage sources available:

• View lineage — every view and the tables and views it reads, optionally with column-level detail straight from SQL Server’s own dependency information rather than parsed from text.
• Query lineage — what the queries that actually ran did, read from Query Store and the dynamic management views. You control how many queries are analysed, how often a query must have run to count, and which patterns to ignore.
• Foreign keys as references, and stored procedures and Agent jobs as metadata when you enable them.

Each of these is a separate switch under the extraction settings, so you can take table lineage without paying for a query-history sweep. See Lineage & Relationships.