How the engine performs, and how it is secured
Every figure on this page was measured against a running deployment, and every security claim describes a mechanism in the request path. Where something is a design limit rather than a result, it says so.
Performance & scale
The numbers below are server-side: what the engine records for itself inside each request, excluding the network distance between a caller and the workspace. That distinction matters, because a test run from a distant laptop can spend more time on the wire than in the engine.
Latency does not scale with response sizeMeasured
| Rows returned | Payload | Median, server-side | Fastest |
|---|---|---|---|
| 10 | 5 KB | 1416 ms | 1121 ms |
| 100 | 52 KB | 1346 ms | 912 ms |
| 1,000 | 521 KB | 1241 ms | 941 ms |
| 5,000 | 2.6 MB | 1397 ms | 972 ms |
| 10,000 | 5.2 MB | 1071 ms | 954 ms |
Returning a thousand times more data costs nothing measurable. There is no upward trend across three orders of magnitude. The spread between sizes is smaller than the run-to-run variance, and the fastest response at every size lands within 60 ms of the same floor.
That tells you where the time goes. Roughly a second of fixed cost, the warehouse round trip, resolving the API definition, connection handling, dominates every request, and the marginal cost of rows and bytes disappears inside it.
Practical consequence for integrators
Paginating in small pages pays that fixed second once per page for no benefit. Asking for large pages is close to free. Size your page to the data you actually need, not to a default.
Behaviour under concurrent loadMeasured
| Concurrent callers | Requests | Throughput | Median | Errors |
|---|---|---|---|---|
| 4 | 8 | 1.37 req/s | 2950 ms | 0 |
| 8 | 16 | 2.25 req/s | 3207 ms | 0 |
Throughput rises with concurrency while latency stays broadly flat: the engine absorbs parallel load rather than serialising it. Both rows were driven from a distant client, so they understate real capacity: the generator could not push requests fast enough to saturate the server.
Tenant isolationMeasured
Databricks' SQL driver is synchronous. Executed naively, a single long-running report would block every other request in the process, including ones that never touch the warehouse. Queries therefore run in a worker pool, with warehouse connections held in a bounded, thread-safe pool.
The effect is measurable. While eight heavy queries run continuously, a request touching only metadata slows by 1.05×, against 1.51× before that work. One demanding consumer does not degrade everyone else's APIs.
How it scales
The engine is sized to whatever SQL warehouse it is pointed at, and the warehouse is the governing term. The deployment measured here runs a 2X-Small serverless warehouse on a single cluster, the smallest configuration available. A larger warehouse with several clusters raises the ceiling proportionally, from the same code and the same configuration file.
Application-side concurrency is set to match: worker processes multiplied by a per-worker connection pool, both deployment settings rather than code changes. When that pool is saturated the engine returns an explicit, immediate error rather than queueing indefinitely, so a saturated system is visible instead of merely slow.
Cold startBy design
A serverless warehouse stops when idle. The first call after a quiet period pays its start-up before any query runs; the slowest response recorded in testing was 16.1 seconds on exactly that path, with every subsequent request back at the one-second floor. The idle timeout is a warehouse setting you control, trading idle compute cost against first-call latency.
What happens in a request
- Platform authenticationThe Databricks Apps proxy authenticates the caller before any application code runs.
- API key validationThe key is hashed and matched against the endpoint it was issued for.
- Definition resolutionThe API and its dataset are resolved at request time. Publishing never requires a restart or redeploy.
- Query constructionIdentifiers are whitelisted and quoted; every caller-supplied value is bound as a parameter.
- ExecutionRun on your SQL warehouse, as the calling user wherever their identity is available.
- AuditStatus, latency, caller and parameters are written to the usage log.
Security architecture
The posture rests on one architectural decision: the engine creates no new Unity Catalog objects and copies no data. There is no second copy to secure, expire or leak, and no shadow permission model to keep aligned with the real one.
Two independent authentication gatesArchitecture
Every request passes the Databricks platform gate before application code executes, and then the engine's own API key check. A workspace token alone reaches the app but not the data; an API key alone does not reach the app at all. Compromise of either in isolation is insufficient.
API key handlingArchitecture
| Property | Implementation |
|---|---|
| Entropy | 256 bits, from the operating system's cryptographic random source |
| At rest | SHA-256 digest only. The raw key is never stored, anywhere |
| Disclosure | Shown once at creation; afterwards only a short prefix, for identification |
| Scope | Bound to a single endpoint, valid across that endpoint's versions and no others |
| Revocation | One record per key, so revoking stops every version at once |
Why SHA-256 rather than a slow password hash
Password hashes are deliberately slow because human passwords carry little entropy and must resist offline guessing. These keys are 256-bit random values, where guessing is not a threat that exists. A plain cryptographic digest is the correct primitive here, and it keeps validation cheap enough to run on every request.
Query constructionArchitecture
Two separate mechanisms, applied to two separate classes of input.
Identifiers, catalog, schema, table, column and alias names, cannot be parameterised in SQL, so each is validated against a strict character pattern before being quoted. Anything outside that set is rejected outright rather than escaped.
Values, filters, search terms, pagination, are never interpolated into SQL text. They are bound as native parameters, including every element of a multi-value list filter.
Joins are assembled from structured column references rather than free-form SQL, even though only an authenticated builder can define them. Filter operators are additionally validated against each column's data type, so an operator a column cannot support is refused before any statement reaches the warehouse.
Permissions stay yoursArchitecture
Where the platform supplies the calling user's identity, the query executes as that user. Unity Catalog's row- and column-level policies apply per caller, evaluated by Databricks itself. The engine does not interpret, cache or reimplement those policies. It has no permission model of its own that could drift out of alignment with yours.
Catalog browsing in the builder works the same way, so someone composing a dataset sees only the catalogs, schemas and tables they can already access.
SecretsArchitecture
No database password exists for the managed control-plane store. Databricks mints a short-lived credential on demand, refreshed ahead of expiry, never written to configuration or logs. Where you supply your own external database instead, those credentials live in a Databricks secret scope private to the application's own identity.
Audit trailArchitecture
Every call is recorded with the key used, timestamp, status, latency, caller address and query parameters, queryable per API. Because parameters are captured verbatim, review the retention policy alongside your own data-classification rules if callers will filter on values that are themselves sensitive.
On the roadmap
Stated plainly, because an evaluator will ask.
| Area | Status | Detail |
|---|---|---|
| Per-key request quotas | Roadmap | Quotas are recorded per key today; enforcement with standard rate-limit responses is in progress |
| Key expiry and rotation | Roadmap | Keys are currently valid until explicitly revoked |
| Definition caching | Roadmap | The clearest remaining latency saving, now that fixed cost is shown to dominate |
| Write and mutation endpoints | Roadmap | The engine serves reads today |
| Tail-percentile publication | Roadmap | Sample sizes so far support a median and a floor; p95 and p99 need a sustained in-region load test |
Measurements were taken against a deployed instance backed by a 2X-Small single-cluster serverless SQL warehouse, the smallest configuration Databricks offers. Latency and throughput scale with warehouse sizing, and figures should be re-measured against your own environment before being treated as a commitment. Client-observed timings in any test run from outside the cloud region include that network distance and will read considerably higher than the server-side figures published here.
Want these numbers from your own environment?
A 30-minute architecture review, measured against your warehouse and your Unity Catalog setup.
Book a FREE Demo