Announcing Procedure Cache

Data API builder (DAB) has long supported Level 1 cache for tables and views. Level 1 is an in-memory cache that automatically stores frequent queries or slow-changing data in the API layer, bypassing several database queries.

Today, Data API builder (DAB) also supports Level 1 cache for stored procedures. This is important. Minimizing long-running procedure calls can dramatically increase the number of concurrent calls your Data API can support.

How does it get configured?

The Data API builder (DAB) settings file configures cache at both the global level (under the runtime property) and at each entity. The time-to-live (TTL) setting can be set globally and used as a shared default or individually configured for each entity – the default is 5 seconds when not customized. By just enabling cache, your API is elevated to the next level.

{
  "runtime": {
    "cache": { // global
        "enabled": true,
        "ttl-seconds": 1
    }
  },
  "entities": {
    "MyProc": {
      "cache": { // entity
        "enabled": true,
        "ttl-seconds": 1
      }
    }
  }
}

Cache Command Line

Some settings in the Data API builder (DAB) configuration file aren’t available in the CLI, so they must be edited manually in the JSON file. While that works, it’s not as convenient as using the command line.

Caching, however, is supported in the CLI for runtime configuration. This means you can update configurations programmatically. Many developers prefer the reliability and repeatability of a CLI, and we do too. We are working to bring every feature, including entity-level caching configuration into the CLI in future releases.

> dab configure --runtime.cache.enabled true
> dab configure --runtime.cache.ttl-seconds 5

Cache considerations

Your database was built to be queried, but the more you query it, the harder it works. For better performance, query your database less. As crazy as that may sound, an API cache strategy makes it possible. Data API builder (DAB) stores frequent queries or slow-changing data in your API layer, dramatically reducing database demand—making an economical medium-sized database feel more like an extra-large.

Managing concurrency means handling many simultaneous requests. As concurrency increases, your API, database connections, and databases must balance competing resources and parallelism constraints. This slows queries and inevitably limits user capacity. An API cache strategy reduces wait times and combines multiple requests into fewer.

Is it worth it?

Data API builder (DAB) caching can cut user wait times from seconds to milliseconds and scale database support from 10 to 1,000 times more concurrent users. To illustrate this, here are load test results for 20 concurrent requests over just 20 seconds against a stored procedure taking 5 seconds to execute. This is with a 1 second TTL. Your results could vary.

How does it work?

Data API builder (DAB) cache uses FusionCache—a mature open-source library widely used in enterprise applications. This reinforces that DAB isn’t an exotic Data API implementation but the kind of solution your team would build with unlimited budget and time.

Does DAB cache support REST endpoints? Yes. DAB supports REST and OpenAPI. When configured, each entity endpoint supports caching. However, remember that caching is configured per entity, allowing flexibility based on your use case.

Does DAB cache support tables, views, and stored procedures? Yes. Until version 1.3, DAB supported only tables and views. Since then, stored procedures (with or without parameters) are also fully supported. This means every database object can enable cache.

Does DAB cache support GraphQL? No. While GraphQL isn’t inherently incompatible with caching, implementing a generic solution is complex. Since DAB dynamically generates GraphQL schemas and uses deeply nested resolvers, caching would require extensive customization and come with significant limitations. At least for now: no.

Does DAB encrypt data in cache? No. This is an important consideration when planning a cache strategy. While data is flowing through your Data API, cached data is at rest and in memory. In most cases, this isn’t a concern, but storing unencrypted sensitive information in memory in certain hosting environments may violate corporate policies.

What’s next?

Level 1 cache is in-memory. Level 2 cache is offloaded to an external system like Redis. Today, we support Level 1 cache, and we’re working to add Level 2 cache with Redis. This is made easier by our use of FusionCache, which already supports Level 2 caching. Stay tuned.

How do I get it?

A startling number of DAB users are still running outdated versions of the engine, risking bugs and missing security fixes. Since version 1.3, Data API builder (DAB) has supported Level 1 cache for tables, views, and stored procedures. This month, we’re releasing the 1.4 stability update. Each update refreshes both the DAB engine container image and the CLI tooling. Make sure you’re using the latest of both. https://aka.ms/dab

Join the Team

Data API builder (DAB) is open source and driven by the community. Visit our GitHub repository (https://aka.ms/dab) to find an open invitation at the top of the README. Join the conversation, help shape the roadmap, and be the first to know about new features.