JDBC DatabaseMetadata.getFunctions does not return user defined scalar functions from lakehouse

Hi n_campbell, 

It’s a limitation of the Lakehouse SQL analytics endpoint today.

You can create and call T-SQL functions in a Lakehouse, but the endpoint’s metadata surface is incomplete and doesn’t populate JDBC DatabaseMetaData.getFunctions (and similarly getProcedures). The same code works against a Fabric Warehouse because Warehouse now exposes UDF metadata via the JDBC driver. See: Lakehouse SQL endpoint overview (note that it’s read-only over Delta but lets you define functions) docs, and Warehouse UDF support announced in 2025 blog and blog. For how getFunctions is supposed to work in the SQL Server JDBC driver, see docs. There’s also another thread confirming that Lakehouse returns nothing while Warehouse does return metadata community.

Practical workarounds:

1. If you need discoverability via JDBC metadata, point the code at a Warehouse (even a lightweight one) instead of the Lakehouse endpoint.
2. From Lakehouse, enumerate functions with a direct T-SQL query (catalog views are partially available; may vary by tenant):

-- May work in Lakehouse SQL endpoint; not guaranteed in all tenants SELECT SCHEMA_NAME(o.schema_id) AS schema_name, o.name AS function_name, o.type_desc FROM sys.objects AS o WHERE o.type IN ('FN','TF','IF') -- scalar, table-valued, inline table-valued ORDER BY schema_name, function_name; 

If sys.objects isn’t exposed, try INFORMATION_SCHEMA.ROUTINES (coverage can be limited in Lakehouse):

SELECT ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_TYPE FROM INFORMATION_SCHEMA.ROUTINES WHERE ROUTINE_TYPE = 'FUNCTION' ORDER BY ROUTINE_SCHEMA, ROUTINE_NAME; 

1. As a last resort, maintain a small registry table of functions during deployment and query that table instead of JDBC metadata.

Sanity check: ensure the first parameter you pass to getFunctions is the Lakehouse SQL endpoint catalog (the Lakehouse’s database name). You can also pass null for catalog and schema to let the driver use the current database/schema. But even with correct patterns, Lakehouse currently returns an empty result set via JDBC.

If this behavior blocks you, I’d recommend logging or upvoting an idea. In the meantime, Warehouse is the safest path when your tooling relies on JDBC metadata discovery.

If you found this helpful, consider giving some Kudos. If I answered your question or solved your problem, mark this post as the solution.