Sources

Tested end to end: a lakehouse with schemas (the demo workspace's demo_lh, schema shop), read through its SQL analytics endpoint. Experimental: warehouses and Fabric SQL databases, read the same way through their SQL endpoint and covered by unit tests; warehouses also give declared keys and foreign keys (rules K0 and R0). Experimental: the mirrored and Snowflake item types below. Tables a lakehouse holds as OneLake shortcuts (to another lakehouse, a warehouse, ADLS or S3) are listed by its SQL analytics endpoint like its own tables, so they are planned with it.

Krusgraph reads sources through Fabric, so data that lives elsewhere takes one of two routes:

1. Bring it into Fabric. A Snowflake database item, a Mirrored database (Snowflake, Azure SQL, Cosmos DB, SAP via Datasphere, …), a Mirrored Azure Databricks catalog or a Mirrored catalog (preview) is a source like a lakehouse: list_sources shows it, plan_backend plans it and create_backend builds the API over its SQL analytics endpoint. The item is set up once in the Fabric portal; Krusgraph reads the endpoint id from the item, as Microsoft's REST specification documents it for each of these item types. Experimental: unit-tested, not yet run against a live item.
2. Plan it where it is. The engine reads INFORMATION_SCHEMA, which Snowflake and Databricks (Unity Catalog) expose like the Fabric SQL endpoint does. The open-source library, the CLI and the local fabric-backend-mcp server give you the graph, the rules, the diagram and the Rayfin entities straight from those systems (for Databricks with its own adapter, below); the API for GraphQL item is a Fabric object, so that last step needs route 1.

Snowflake has no KEY_COLUMN_USAGE view, so keys there come from names (rule K2) and are shown as such. Unity Catalog's informational primary and foreign keys are read as declared keys (K0, R0). The item types, routes and sqlEndpointProperties follow Microsoft's published REST specification; these source types are experimental until a live run.