Hi,

1. Out-of-the-box REST/GraphQL for metric views?

Databricks does not appear to provide a Metric View-specific REST or GraphQL query API. Metric Views are queried through the Databricks SQL engine using SQL, including the MEASURE() function for measures.

However, external applications do not necessarily need a custom database connector. Databricks provides the SQL Statement Execution REST API, which can execute SQL against a SQL warehouse and return the result. Therefore, an external API/service can query Metric Views through this API.

So the basic pattern would be:

Custom Application → Application/API layer → Databricks Statement Execution API → SQL Warehouse → UC Metric View

2. Custom API/service layer?

For workloads where interactive analytical latency is acceptable, I would keep the Metric View as the authoritative semantic layer and query it directly through Databricks SQL. Metric Views now also support native materialization. Check docs.

Materialization for metric views | Databricks on AWS

3. Latency/Concurrency

Lakehouse//RT is currently Beta and is specifically positioned for low-latency, high-concurrency analytical workloads, including serving analytical data to custom applications. Databricks documents sub-second SQL reads for hundreds to thousands of concurrent users, and Metric Views are explicitly supported. 
If you need such high QPS then it's worth a try.

4. Lakebase

Lakebase is better aligned with operational application-serving patterns: millisecond-style key lookups, transactional workloads, large numbers of application connections, or situations where application data and analytical data need to be queried together.

Databricks provides synced tables, which replicate Unity Catalog tables, views, and materialized views into Lakebase Postgres specifically for low-latency application access. The synchronization is managed through Lakeflow pipelines.

In addition, Lakebase now provides a Data API, a PostgREST-compatible REST interface that automatically generates REST endpoints from the Postgres schema. This can potentially remove the need to build a simple CRUD/read API service at all.