# Caching - Ref: `capability:caching` - Page: https://onedevatlas.dev/capabilities/caching - JSON: https://onedevatlas.dev/capabilities/caching.json - Records: all ecosystems https://onedevatlas.dev/capabilities/caching.md, CAP https://onedevatlas.dev/cap/capabilities/caching.md, CAP / Node.js https://onedevatlas.dev/cap/node/capabilities/caching.md, CAP / Java https://onedevatlas.dev/cap/java/capabilities/caching.md, BTP/BAIP https://onedevatlas.dev/btp/capabilities/caching.md, ABAP https://onedevatlas.dev/abap/capabilities/caching.md, ABAP / Standard ABAP https://onedevatlas.dev/abap/standard-abap/capabilities/caching.md, ABAP / ABAP Cloud https://onedevatlas.dev/abap/abap-cloud/capabilities/caching.md - Door: CAP https://onedevatlas.dev/cap.md, BTP/BAIP https://onedevatlas.dev/btp.md, ABAP https://onedevatlas.dev/abap.md - Record schema: https://onedevatlas.dev/schema/capability.schema.json - Index: https://onedevatlas.dev/llms.txt - Generated: 2026-10-26 > Drafted with AI. This text was drafted by a language model from the sources named on this page and reviewed by a person before publication. EU AI Act, Art. 50. Holding the result of an expensive read so the next one is cheap. This spans four different things people call caching — HTTP response caching, query result caching, remote service response caching, and application-level memoisation. They are not interchangeable, and picking the wrong one is the usual cause of stale-data bugs in multitenant apps. - Domain: Data & Persistence - Ecosystems: CAP, BTP/BAIP, ABAP ## Who is present ### CAP Caching in CAP can mean HTTP response validation, retaining the result of a query or function, or querying a replicated copy of service data. The core, application plugins and a backing store answer different parts of that concern. HTTP response caching, query-result caching, remote-service response caching and application-level memoisation are different choices; stale-data behaviour and tenant isolation need to be considered for the chosen layer. - Coverage: SAP and community, assessed 2026-09-17 - SAP's answer: built into [@sap/cds](https://onedevatlas.dev/artifacts/sap-cds) - Relationship between core and community: unassessed What the core does: CAP supports HTTP cache validation through ETags. CAP Java also sets Cache-Control max-age headers on annotated stream properties. Where it stops: ETags validate a resource version and the Java annotation controls HTTP response freshness; these mechanisms do not specify an application result-cache store or a replicated service database. What the community adds: [cds-caching](https://onedevatlas.dev/artifacts/cds-caching) retains query, request and function results; [@cap-js-community/common](https://onedevatlas.dev/artifacts/cap-js-community-common) replicates service data into SQLite. [cds-data-federation](https://onedevatlas.dev/artifacts/mikezaschka-cds-data-federation) exposes response and entity-snapshot caching for federated data. In cds-caching, tenant-aware keys are enabled automatically in MTX unless explicitly disabled. - Sources: - [capire — Generic Service Providers](https://cap.cloud.sap/docs/guides/services/served-ootb), checked 2026-09-17: “caching techniques using ETags” - [capire — Cache Control in Java](https://cap.cloud.sap/docs/guides/uis/fiori), checked 2026-09-17: “The Cache Control feature is currently supported only on the Java runtime.” - [cds-caching — README](https://github.com/mikezaschka/cds-caching/blob/main/README.md), checked 2026-09-17: “Transparently cache CQN queries, CAP requests, or function calls” - [CAP Node.js Community Common — Replication Cache](https://github.com/cap-js-community/common/blob/main/README.md), checked 2026-09-17: “The replication cache allows to cache a service (e.g. db service) into a tenant-aware SQLite database.” - [cds-caching — Tenant and user isolation](https://github.com/mikezaschka/cds-caching/blob/main/docs/security.md), checked 2026-09-17: “`isTenantAware` defaults to `true` when multitenancy is detected, so tenants are separated by default in MTX mode.” - [cds-data — README](https://github.com/mikezaschka/cds-data), checked 2026-09-17: “Federation optionally layers [cds-caching](https://github.com/mikezaschka/cds-caching) on delegate or replicate.” ### BTP/BAIP - Coverage: SAP only, assessed 2026-09-09 What the core does: [Redis](https://onedevatlas.dev/externals/redis) on SAP BTP, in a hyperscaler edition and an older one, is the managed cache an application binds; there is no application-level caching layer in the platform, the store is the answer. - Sources: - [Redis, hyperscaler option — SAP btp-service-metadata v1](https://github.com/SAP-samples/btp-service-metadata/blob/main/v1/developer/redis-cache.json), checked 2026-09-09 - [Redis on SAP BTP — SAP btp-service-metadata v1](https://github.com/SAP-samples/btp-service-metadata/blob/main/v1/developer/redis.json), checked 2026-09-09 ### ABAP On ABAP the platform's cache is the table buffer on the application server, configured per table and used without code; memoising anything else, such as the SCARR rows or cl_salv_table references in the examples of [ABAP-CACHE-BOX](https://github.com/furkancosgun/ABAP-CACHE-BOX), is written into the program. - Coverage: SAP and community, assessed 2026-09-14 - Relationship between core and community: unassessed What the core does: Table buffering keeps rows of a database table in the shared memory of the application server, switched on and typed as single-record, generic or full buffering in the table's technical settings, and ABAP SQL reads use the buffer without code. Where it stops: At table rows. A value a program computes or an object it builds is not a table read, so holding it for reuse within the program is the program's own code. What the community adds: Application-level memoisation: macros that generate a singleton cache class per data type or object type, backed by a hashed table. - Sources: - [ABAP Keyword Documentation 7.52 — Table Buffering of Database Tables](https://help.sap.com/doc/abapdocu_752_index_htm/7.52/en-US/abenddic_database_tables_buffer.htm), checked 2026-09-14: “If possible, the database interface redirects any reads to the table buffer in the shared memory of the application server.” - [ABAP cheat sheets — Performance Notes](https://github.com/SAP-samples/abap-cheat-sheets/blob/main/32_Performance_Notes.md), checked 2026-09-14: “The table buffering is applied implicitly when the database is accessed using ABAP SQL.” ## What people use it for ### Cache a remote service response A read that would call out to a remote service on every request is answered from a retained response until it expires. - Boundary: Covers a response from a service the application calls out to. Retaining the result of a local query is a separate task, and so is copying the remote data into a local database and querying that. - Assessed: 2026-09-19, CAP / Node.js Contributions: - [cds-caching](https://onedevatlas.dev/artifacts/cds-caching), result cache: documented. cache.rt.send takes the request and the remote service and returns the retained response with the ttl the call states. The call is written where the application would otherwise send to the service. - Remaining work: Choose the ttl and call the cache instead of the service. The plugin documents the call, not which reads are worth retaining. - Read at: README at mikezaschka/cds-caching commit 2ad749c. - [cds-caching — Read-Through Caching for remote services](https://raw.githubusercontent.com/mikezaschka/cds-caching/2ad749c2b47186cb740efb61c8022d6a1bee8f9c/README.md), checked 2026-09-19: “const { result } = await cache.rt.send(request, remoteService, { ttl: 10000 })” - [cds-caching — README](https://raw.githubusercontent.com/mikezaschka/cds-caching/2ad749c2b47186cb740efb61c8022d6a1bee8f9c/README.md), checked 2026-09-19: “Transparently cache CQN queries, CAP requests, or function calls” - [cds-data-federation](https://onedevatlas.dev/artifacts/mikezaschka-cds-data-federation), federated read adapter: documented, under conditions. On a delegated entity the response strategy routes the federated read through cds-caching, so the retaining is declared on the consumption view rather than written into a handler. The entity strategy answers a different shape of the same wish: it stores a snapshot of the remote projection in secondary SQLite and serves reads from there until the ttl runs out. - Remaining work: Install the peer dependency and annotate the view. The strategy selects a cache, it is not a second one; the entity strategy brings cds-data-pipeline and @cap-js/sqlite with it. - Remaining work is: Configuration - Conditions: cache.strategy is left at its default of response; cds-caching is installed, which the page names as an optional peer dependency - [cds-data-federation — Caching Federated Entities, response strategy](https://mikezaschka.github.io/cds-data/federation/integration/caching.html), checked 2026-09-19: “cache.strategy: 'response' (default) — provided by cds-caching, an optional peer dependency.” - [cds-data-federation — Caching Federated Entities, entity strategy](https://mikezaschka.github.io/cds-data/federation/integration/caching.html), checked 2026-09-19: “stores a full remote projection snapshot in secondary SQLite via cds-data-pipeline, then satisfies arbitrary READ CQNs from SQLite until TTL.” - [cds-data-federation — Caching Federated Entities, packages](https://mikezaschka.github.io/cds-data/federation/integration/caching.html), checked 2026-09-19: “npm add cds-data-pipeline @cap-js/sqlite” - [@sap/cds](https://onedevatlas.dev/artifacts/sap-cds), core runtime: assessed, not established. Whether the CAP Node.js runtime retains a remote service response is not established here. Capire's CAP-level Service Integration guide, read on 2026-09-19, covers importing an API, integrating the model and writing the integration logic, and does not mention caching. - Remaining work: Read the remote services and destinations documentation on capire before treating this as settled. Absence from the integration guide is not a statement that the runtime does nothing. Content: - [The Full Picture: Federating, Replicating, and Caching Remote Data in CAP — Part 1](https://onedevatlas.dev/content/federating-replicating-and-caching-remote-data-in-cap-part-1): Fixes the vocabulary this task sits in: delegation forwards each request to the remote at query time, replication is a scheduled copy, and caching is an option on either rather than a third strategy. Written by the maintainer of the plugins it describes. - [Federating, Replicating, and Caching Remote Data in CAP — Part 2](https://onedevatlas.dev/content/federating-replicating-and-caching-remote-data-in-cap-part-2): The walkthrough half: one application that federates, replicates and caches remote data, step by step, with the finished project published. Unknowns: - Whether a response retained through the federation adapter carries the same user and locale key awareness as a direct cds-caching call is not stated on the federation caching page read here. - No capire page documenting the core's behaviour for remote service calls was located for this assessment. Two guessed URLs returned 404 on 2026-09-19. ### Cache the result of a function call A function the application would otherwise run on every call returns a value retained from an earlier call until it expires. - Boundary: Covers retaining what a function returns, under a key that carries the arguments it was called with. Retaining the result of a query and retaining a response from a remote service are separate tasks, and so is where the retained value is kept. - Assessed: 2026-09-27, CAP / Node.js Contributions: - [cds-caching](https://onedevatlas.dev/artifacts/cds-caching), result cache: documented. Two routes to the same outcome. A @cache annotation on a function in the CDS model retains what it returns for the ttl it states, so the decision sits on the declaration. In code, cache.rt.wrap takes a name and the function and hands back a cached version of it, and cache.rt.exec runs a function once with its arguments and retains what came back. The arguments are part of the generated key, so a call with different arguments is held separately. - Remaining work: Name the function and choose the ttl. Whether a function returns the same value for the same arguments stays the application's to decide: the pages read here document the key and the expiry, not which functions are worth retaining or safe to retain. - Remaining work is: Configuration - Read at: README and docs/key-management.md at mikezaschka/cds-caching commit 2ad749c. - [cds-caching — README](https://raw.githubusercontent.com/mikezaschka/cds-caching/2ad749c2b47186cb740efb61c8022d6a1bee8f9c/README.md), checked 2026-09-27: “Transparently cache CQN queries, CAP requests, or function calls” - [cds-caching — Annotation-Based Caching, function](https://raw.githubusercontent.com/mikezaschka/cds-caching/2ad749c2b47186cb740efb61c8022d6a1bee8f9c/README.md), checked 2026-09-27: “@cache: { ttl: 60000 } function getRecommendations() returns array of Products;” - [cds-caching — Read-Through Caching, wrapped function](https://raw.githubusercontent.com/mikezaschka/cds-caching/2ad749c2b47186cb740efb61c8022d6a1bee8f9c/README.md), checked 2026-09-27: “const cachedFn = cache.rt.wrap("bp-data", fetchBPData, { ttl: 3600, tags: ['bp'] })” - [cds-caching — Read-Through Caching, one-off execution](https://raw.githubusercontent.com/mikezaschka/cds-caching/2ad749c2b47186cb740efb61c8022d6a1bee8f9c/README.md), checked 2026-09-27: “const { result } = await cache.rt.exec("product", fetchProduct, ["1000001"], { ttl: 3600 })” - [cds-caching — Key management, wrapped functions](https://raw.githubusercontent.com/mikezaschka/cds-caching/2ad749c2b47186cb740efb61c8022d6a1bee8f9c/docs/key-management.md), checked 2026-09-27: “For wrapped functions, the cache key is generated based on function arguments and global context:” - [cds-caching — Key management, default template](https://raw.githubusercontent.com/mikezaschka/cds-caching/2ad749c2b47186cb740efb61c8022d6a1bee8f9c/docs/key-management.md), checked 2026-09-27: “**Default template:** `{baseKey}:{args[0]}:{args[1]}:...:{args[n]}` (if no global context enabled)” - [@sap/cds](https://onedevatlas.dev/artifacts/sap-cds), core runtime: assessed, not established. Whether the CAP Node.js runtime retains what a function returns is not established here. No capire page documenting a result cache for a function or an action was located for this assessment. - Remaining work: Read the Node.js runtime and performance documentation on capire before treating this as settled. Nothing read here states that the runtime does this, and nothing read here states that it does not. Unknowns: - The key-management page states that global context is prepended to the function template. Which of user, tenant and locale is on by default for a function cache in particular was not established from the pages read here. - The plugin's introduction post, already attached to this capability, returned HTTP 403 on 2026-09-27, so no reading was checked for whether it shows a function cache working. - Only cds-caching was assessed for this outcome. The other CAP providers on this capability document copying a service and caching a federated entity read, which are a different shape, and this record does not assess either of them for a function result. ### Keep a cached result from reaching the wrong tenant, user or locale A result retained for one tenant, one user or one language is not returned to a request that belongs to another. - Boundary: Covers the key a retained entry is held under and where the store keeps it. Tenant isolation of the application's own data, and the subscription mechanics themselves, belong to multitenancy and are assessed there. Nothing here establishes that a leak was observed or ruled out in any application. - Assessed: 2026-09-19, CAP / Node.js Contributions: - [cds-caching](https://onedevatlas.dev/artifacts/cds-caching), key isolation: documented, under conditions. Tenant, user and locale are three separate dimensions of the cache key with three different defaults. Tenant awareness turns itself on when multitenancy is detected. User awareness is the application's to set, because a result a handler filters after the query has run carries the same key for every caller. Locale is off, so responses in different languages share one entry until it is switched on. Where the entries sit follows the store: with the cds store each tenant's cache data is held in that tenant's own HDI container. - Remaining work: Decide per cache which dimensions belong in the key and set the ones that do not default. The plugin documents the switches, not which of an application's responses vary by user or language. - Conditions: Multitenancy is detected, which is what turns tenant-aware keys on, and the opt-out is not set; User awareness is set for caches whose responses vary per user without the query varying; Locale awareness is set for caches holding translated texts - Read at: README and docs/security.md at mikezaschka/cds-caching commit 2ad749c. - [cds-caching — Multi-tenancy, tenant-aware keys](https://raw.githubusercontent.com/mikezaschka/cds-caching/2ad749c2b47186cb740efb61c8022d6a1bee8f9c/README.md), checked 2026-09-19: “`isTenantAware` is automatically set to `true` in MTX mode.” - [cds-caching — Tenant and user isolation, tenant default](https://raw.githubusercontent.com/mikezaschka/cds-caching/2ad749c2b47186cb740efb61c8022d6a1bee8f9c/docs/security.md), checked 2026-09-19: “so tenants are separated by default in MTX mode.” - [cds-caching — Tenant and user isolation, responses that vary by user](https://raw.githubusercontent.com/mikezaschka/cds-caching/2ad749c2b47186cb740efb61c8022d6a1bee8f9c/docs/security.md), checked 2026-09-19: “the query is identical for every caller and so is the key” - [cds-caching — Tenant and user isolation, locale](https://raw.githubusercontent.com/mikezaschka/cds-caching/2ad749c2b47186cb740efb61c8022d6a1bee8f9c/docs/security.md), checked 2026-09-19: “so responses in different languages share one entry” - [cds-caching — Multi-tenancy, cds store](https://raw.githubusercontent.com/mikezaschka/cds-caching/2ad749c2b47186cb740efb61c8022d6a1bee8f9c/README.md), checked 2026-09-19: “With `store: 'cds'`, each tenant's cache data lives in its own HDI container” - [@cap-js-community/common](https://onedevatlas.dev/artifacts/cap-js-community-common), service replica: documented, under conditions. The replica is held in a tenant-aware SQLite database, so each tenant queries its own copy. One annotation opts out of that: static replication is stated as non-tenant aware, which is the arrangement for rows that are the same for everyone. - Remaining work: Check every entity annotated for static replication for whether its rows really are the same for all tenants. User and locale are not dimensions this section names at all. - Conditions: The entity is not annotated for static replication, which the README states is not tenant aware - Read at: README at cap-js-community/common commit e1abccc. - [CAP Node.js Community Common — Replication Cache](https://raw.githubusercontent.com/cap-js-community/common/e1abccca5c67218ec548150b9c183e229d5b2419/README.md), checked 2026-09-19: “The replication cache allows to cache a service (e.g. db service) into a tenant-aware SQLite database.” - [CAP Node.js Community Common — Replication Cache, static replication](https://raw.githubusercontent.com/cap-js-community/common/e1abccca5c67218ec548150b9c183e229d5b2419/README.md), checked 2026-09-19: “`@cds.replicate.static: Boolean`: Statically replicate non-tenant aware” Unknowns: - Whether entries written before user or locale awareness was switched on are dropped or kept is not stated in the guide read here. - Nothing read here states what happens to keys already held in a shared Redis store when a tenant is offboarded. - Whether a response retained through cds-data-federation carries the same key dimensions as a direct cds-caching call is not stated on the federation caching page. ### Refresh cached reads after a write A read answered from a cache reflects a write to the underlying data within a bound the application sets. - Boundary: Covers what clears or ages out a retained result. Which reads are retained, and where they are kept, are separate tasks. - Assessed: 2026-09-19, CAP / Node.js Contributions: - [cds-caching](https://onedevatlas.dev/artifacts/cds-caching), result cache: documented. invalidateOnWrite clears the cached queries for an entity when its data changes, registered as after handlers for CREATE, UPDATE and DELETE. Tags are the other route: keys set under a tag are cleared together by deleteByTag, which is how a write can clear a result assembled from several keys. - Remaining work: Set the flag per entity, or assign tags and call deleteByTag from the handler that writes. A write that reaches the data by another route is not covered by either. - Remaining work is: Configuration, Application code - Read at: README at mikezaschka/cds-caching commit 2ad749c. - [cds-caching — Automatic Invalidation on Write](https://raw.githubusercontent.com/mikezaschka/cds-caching/2ad749c2b47186cb740efb61c8022d6a1bee8f9c/README.md), checked 2026-09-19: “For annotation-based entity caching, use `invalidateOnWrite` to automatically clear all cached queries for an entity whenever its data changes” - [cds-caching — Automatic Invalidation on Write, handlers](https://raw.githubusercontent.com/mikezaschka/cds-caching/2ad749c2b47186cb740efb61c8022d6a1bee8f9c/README.md), checked 2026-09-19: “This registers `after` handlers for CREATE, UPDATE, and DELETE that call `deleteByTag` with an entity-level tag. All cached variants (filtered, sorted, paginated, single-entity) are invalidated at once.” - [cds-caching — Tag-based invalidation](https://raw.githubusercontent.com/mikezaschka/cds-caching/2ad749c2b47186cb740efb61c8022d6a1bee8f9c/README.md), checked 2026-09-19: “await cache.deleteByTag("bp-list")” - [cds-data-federation](https://onedevatlas.dev/artifacts/mikezaschka-cds-data-federation), federated read adapter: stated not supported. Automatic clearing on a write. A write through a writable delegate does not clear the cache under either strategy, and the documentation records that as a stated behaviour with the alternative named. - Remaining work: Clear the entry from the write path, or shorten the ttl so the window is the staleness the application accepts. - Remaining work is: Configuration, Application code - [cds-data-federation — Caching Federated Entities, writable delegates](https://mikezaschka.github.io/cds-data/federation/integration/caching.html), checked 2026-09-19: “For writable delegates, neither cache strategy auto-invalidates on CUD — plan manual invalidation or shorter TTL.” - [@cap-js-community/common](https://onedevatlas.dev/artifacts/cap-js-community-common), service replica: documented. The replica ages out on a time to live given in milliseconds, and the same annotation block carries auto and preload for when the copy is made. Time is the bound this section states. - Remaining work: Set the ttl per entity. Whether a write through the replicated service clears its copy is not stated in the section read here, so the ttl is the only bound this assessment records. - Remaining work is: Configuration - Read at: README at cap-js-community/common commit e1abccc. - [CAP Node.js Community Common — Replication Cache annotations](https://raw.githubusercontent.com/cap-js-community/common/e1abccca5c67218ec548150b9c183e229d5b2419/README.md), checked 2026-09-19: “`@cds.replicate.ttl: Number`: Time-To-Live (TTL) of cache entry in milliseconds” - [CAP Node.js Community Common — Replication Cache, automatic replication](https://raw.githubusercontent.com/cap-js-community/common/e1abccca5c67218ec548150b9c183e229d5b2419/README.md), checked 2026-09-19: “`@cds.replicate.auto: Boolean`: Replication is managed automatically” Unknowns: - Whether a write through the replicated service clears its replica is not stated in the replication cache section read on 2026-09-19. Absence in that section is not a statement that it does not happen. - invalidateOnWrite is documented for annotation-based entity caching. Whether a result retained through the read-through calls is cleared the same way is not stated in the lines read here. - Nothing read here states what clears a cached result when the underlying data is changed outside the application, by another consumer of the same database or remote system. ### Serve repeated reads of a rarely written entity from a cache Reads of an entity that is read constantly and written rarely are answered inside the application instead of going to the database on every request. - Boundary: Covers retaining the result of a read. Keeping it fresh after a write is a separate task, and so is where the retained result is kept. - Assessed: 2026-09-19, CAP / Node.js Contributions: - [cds-caching](https://onedevatlas.dev/artifacts/cds-caching), result cache: documented. A @cache annotation on a service entity retains the results of reads on it for the ttl it states, and it sits on the projection rather than in a handler. Where the decision belongs in code instead, cache.rt.run takes the query and the service and returns the result with the ttl the call states. - Remaining work: Decide the ttl entity by entity. The annotation is per projection, so each one is its own decision, and nothing picks the entities worth retaining. - Remaining work is: Configuration - Read at: README at mikezaschka/cds-caching commit 2ad749c. - [cds-caching — Annotation-Based Caching](https://raw.githubusercontent.com/mikezaschka/cds-caching/2ad749c2b47186cb740efb61c8022d6a1bee8f9c/README.md), checked 2026-09-19: “@cache: { ttl: 10000 } entity Products as projection on db.Products;” - [cds-caching — Read-Through Caching for CQN queries](https://raw.githubusercontent.com/mikezaschka/cds-caching/2ad749c2b47186cb740efb61c8022d6a1bee8f9c/README.md), checked 2026-09-19: “const { result } = await cache.rt.run(query, db, { ttl: 30000 })” - [cds-caching — README](https://raw.githubusercontent.com/mikezaschka/cds-caching/2ad749c2b47186cb740efb61c8022d6a1bee8f9c/README.md), checked 2026-09-19: “Transparently cache CQN queries, CAP requests, or function calls” - [@cap-js-community/common](https://onedevatlas.dev/artifacts/cap-js-community-common), service replica: documented. Answers the same outcome by a different mechanism: it holds a copy of a service in SQLite and runs the original query against the copy, so the read shape in the application does not change. The README gives the db service as its example. - Remaining work: Install @cap-js/sqlite as a dependency rather than a development dependency, and annotate the entities to replicate. - Remaining work is: Configuration - Read at: README at cap-js-community/common commit e1abccc. - [CAP Node.js Community Common — Replication Cache](https://raw.githubusercontent.com/cap-js-community/common/e1abccca5c67218ec548150b9c183e229d5b2419/README.md), checked 2026-09-19: “The replication cache allows to cache a service (e.g. db service) into a tenant-aware SQLite database.” - [CAP Node.js Community Common — Replication Cache, local query](https://raw.githubusercontent.com/cap-js-community/common/e1abccca5c67218ec548150b9c183e229d5b2419/README.md), checked 2026-09-19: “Local replicated SQLite database can be queried with same query as the original service.” - [CAP Node.js Community Common — Replication Cache, prerequisite](https://raw.githubusercontent.com/cap-js-community/common/e1abccca5c67218ec548150b9c183e229d5b2419/README.md), checked 2026-09-19: “Ensure `@cap-js/sqlite` is installed as dependency (not as dev dependency) in your project.” - [@sap/cds](https://onedevatlas.dev/artifacts/sap-cds), core runtime: assessed, not established. Whether the CAP Node.js runtime holds a query result between requests is not established by the pages read for this assessment. Capire's generic service providers page documents ETag validation, which answers a conditional request rather than retaining a result, and the service integration guide read on 2026-09-19 does not mention caching at all. - Remaining work: Read the CAP Node.js databases and performance documentation before treating this as settled. Two guessed capire URLs for a performance guide returned 404 on 2026-09-19, so the page that would answer it was not located. Content: - [Performance Boost and Caching Strategy for Faster Data Access using "cds-caching" in SAP CAP](https://onedevatlas.dev/content/performance-boost-and-caching-strategy-with-cds-caching): Somebody else's account of exactly this shape: a master-data entity of more than a million rows, rarely written and constantly read, and what integrating the plugin changed in that application. - [Boosting performance in SAP Cloud Application Programming Model (CAP) applications with cds-caching](https://onedevatlas.dev/content/boosting-performance-in-cap-with-cds-caching): The plugin's own introduction post, on the cases it was written against. Its call sites predate version 1.0 and show the read-through calls the README now lists as deprecated. Unknowns: - The replication cache section names a service and gives the db service as its example. Which other services can be replicated is not stated there, so this assessment does not record it for a remote service. - Nothing read here states what happens to entries held in the default memory store when an application instance restarts. ### Share one cache across application instances Several instances of the same application read and write one cache, so a result retained while serving one request answers a later request routed to a different instance. - Boundary: Covers where a retained result is kept. What is retained, and when it expires, are separate tasks. Whether a subaccount may provision a given service plan is a project question and is not assessed here. - Assessed: 2026-09-19, CAP / Node.js - Ways: With the redis store on Redis on SAP BTP Contributions: - [cds-caching](https://onedevatlas.dev/artifacts/cds-caching), result cache: documented, under conditions (on redis-store). The store is configuration rather than code. The table names memory for development and small scale, sqlite for a single instance, redis for production and distributed use, postgres, a direct hana connection, and a cds store that uses the application's own database. Under multitenancy the README states what each of the two production shapes does with tenants: the cds store puts each tenant's cache data in its own HDI container, and the redis store prefixes keys with the tenant. - Remaining work: Set the store, install its adapter package and bind the backing service. Memory is what is configured until then. - Remaining work is: Configuration - Conditions: A store other than the default memory store is configured; The adapter package the store table names for that store is installed - Read at: README at mikezaschka/cds-caching commit 2ad749c. - [cds-caching — Store Types, Redis](https://raw.githubusercontent.com/mikezaschka/cds-caching/2ad749c2b47186cb740efb61c8022d6a1bee8f9c/README.md), checked 2026-09-19: “| Redis | `"redis"` | Production, distributed | `@keyv/redis` |” - [cds-caching — Store Types, CDS database](https://raw.githubusercontent.com/mikezaschka/cds-caching/2ad749c2b47186cb740efb61c8022d6a1bee8f9c/README.md), checked 2026-09-19: “| CDS Database | `"cds"` | Production, HANA, multi-tenant | None (uses app's DB) |” - [cds-caching — Configuration, default store](https://raw.githubusercontent.com/mikezaschka/cds-caching/2ad749c2b47186cb740efb61c8022d6a1bee8f9c/README.md), checked 2026-09-19: “| `store` | `"memory"` | Storage backend (`memory`, `sqlite`, `redis`, `postgres`, `hana`, `cds`) |” - [cds-caching — Multi-tenancy, shared Redis](https://raw.githubusercontent.com/mikezaschka/cds-caching/2ad749c2b47186cb740efb61c8022d6a1bee8f9c/README.md), checked 2026-09-19: “Alternatively, use `store: 'redis'` for shared Redis with automatic tenant-prefixed keys:” - [cds-caching — Multi-tenancy, cds store](https://raw.githubusercontent.com/mikezaschka/cds-caching/2ad749c2b47186cb740efb61c8022d6a1bee8f9c/README.md), checked 2026-09-19: “With `store: 'cds'`, each tenant's cache data lives in its own HDI container” - [Redis on SAP BTP, hyperscaler option](https://onedevatlas.dev/artifacts/btp-redis), managed store: documented (on redis-store). The instance an application binds when the redis store is configured. The plugin's deployment guide provisions service redis-cache in the mta descriptor and tags the instance cds-caching; SAP's service metadata records the plans the service offers, from a free plan for non-productive development to a premium one. - Remaining work: Provision an instance on a plan the subaccount is entitled to and bind it. Which plans a given subaccount may use is a project question, not a documented property of either the service or the plugin. - Remaining work is: Configuration - [cds-caching — Redis on SAP BTP](https://raw.githubusercontent.com/mikezaschka/cds-caching/2ad749c2b47186cb740efb61c8022d6a1bee8f9c/docs/deployment-guide.md), checked 2026-09-19: “Redis can be provisioned as a managed service through the Redis on SAP BTP hyperscaler option.” - [SAP BTP service metadata — Redis, hyperscaler option, premium plan](https://raw.githubusercontent.com/SAP-samples/btp-service-metadata/main/v1/developer/redis-cache.json), checked 2026-09-19: “Create production-ready Redis Cache instances with premium features.” - [SAP BTP service metadata — Redis, hyperscaler option, free plan](https://raw.githubusercontent.com/SAP-samples/btp-service-metadata/main/v1/developer/redis-cache.json), checked 2026-09-19: “Redis cache service for non-productive development usage” Unknowns: - PostgreSQL is named in the same store table and has no artifact entry, so it is not recorded as a contribution here. That is a limit of what the graph admits, not a statement about the store. - Whether an equivalent shared result cache is documented for CAP Java was not established. com.sap.cds:cds-feature-redis connects a messaging service to Redis Pub/Sub, which answers a different concern, and no Java page was read for this task. - Neither the store table nor the deployment guide read here states what happens to entries held in the memory store when an instance restarts, or how two instances behave while one of them still holds an entry the other has cleared. ### Skip resending a record the client already has A client that re-reads an entity it has already fetched gets 304 and no body back when the record has not changed since. - Boundary: Covers a conditional read over HTTP on a served entity. Retaining a query, request or function result inside the application is a separate task, and so is telling a client how long it may reuse what it has without asking again. - Assessed: 2026-09-19, CAP / Node.js, Java Contributions: - [@sap/cds](https://onedevatlas.dev/artifacts/sap-cds), core runtime: documented. A read carrying If-None-Match is answered with 304 and no body while the annotated element still matches. Capire's example is a GET on Employees/111 with the previous timestamp in the header. - Remaining work: Annotate an element with @odata.etag. Capire annotates modifiedAt from the managed aspect, which changes on each modification, and the client has to send back what it received. - Remaining work is: Configuration - [capire — Concurrency Control](https://cap.cloud.sap/docs/guides/services/served-ootb), checked 2026-09-19: “The CAP runtimes support optimistic concurrency control and caching techniques using ETags.” - [capire — Concurrency Control, conditional read example](https://cap.cloud.sap/docs/guides/services/served-ootb), checked 2026-09-19: “304 Not Modified // Record was not changed” - [capire — Concurrency Control, ETag annotation](https://cap.cloud.sap/docs/guides/services/served-ootb), checked 2026-09-19: “annotate Foo with { modifiedAt @odata.etag }” - [com.sap.cds:cds-services-bom](https://onedevatlas.dev/artifacts/cap-java-cds-services-bom), core runtime: documented. Capire states the support for the CAP runtimes rather than for one of them, and the annotation it shows is a CDS annotation on the model both runtimes compile. - Remaining work: The same @odata.etag annotation. The page carries one example and no step specific to Java, so what a Java project does beyond the annotation is not stated there. - Remaining work is: Configuration - [capire — Concurrency Control](https://cap.cloud.sap/docs/guides/services/served-ootb), checked 2026-09-19: “The CAP runtimes support optimistic concurrency control and caching techniques using ETags.” Unknowns: - Whether a 304 answer skips the database read or only the payload is not stated on the capire page read here, so this assessment records the header behaviour and nothing about what the server still does. - The Java runtime is credited from a sentence that names both runtimes together. No Java-side page was read for this task, and https://cap.cloud.sap/docs/java/event-handlers/etags returned 404 on 2026-09-19. ### Tell a client how long a served file stays fresh A client that has fetched a file served by the application keeps using it for a stated number of seconds without asking the application again. - Boundary: Covers the freshness window the application sends with a response. Answering a conditional request with 304, which still costs a round trip, is a separate task, and so is retaining a result inside the application. - Assessed: 2026-09-19, CAP / Node.js, Java Contributions: - [com.sap.cds:cds-services-bom](https://onedevatlas.dev/artifacts/cap-java-cds-services-bom), core runtime: documented. An annotation in the CDS model, @http.CacheControl with a maxAge in seconds on a stream property, sets the Cache-Control header on the response. The page states that max-age counts from when the response was generated on the origin server rather than from when the client received it, so the window a client sees can be shorter than the number in the model. - Remaining work: Annotate the stream property and pick the number of seconds. Nothing recalls a response already sent, so the number is the longest a client may serve content that has since changed. - Remaining work is: Configuration - [capire — Cache Control in Java, annotation](https://cap.cloud.sap/docs/guides/uis/fiori), checked 2026-09-19: “In the CDS model, use the `@http.CacheControl: {maxAge: }` annotation on stream properties.” - [capire — Cache Control in Java, elapsed time](https://cap.cloud.sap/docs/guides/uis/fiori), checked 2026-09-19: “max-age is the elapsed time since the response was generated on the origin server, not the time since the response was received.” - [@sap/cds](https://onedevatlas.dev/artifacts/sap-cds), core runtime: stated not supported. Capire scopes the Cache Control feature to the Java runtime, so the same annotation is not documented as doing anything on Node.js. - Remaining work: Set the header from the application's own code, or take one of the other mechanisms this capability records. The page does not state what a Node.js runtime does with @http.CacheControl when the annotation is in the model. - Remaining work is: Configuration, Application code - [capire — Cache Control in Java, runtime scope](https://cap.cloud.sap/docs/guides/uis/fiori), checked 2026-09-19: “The Cache Control feature is currently supported only on the Java runtime.” Unknowns: - Whether the annotation applies to anything other than a stream property is not stated on the page read here. - Nothing read here states how a client is brought back early when the file changes inside the window it was given. ## Artifacts (6) ### CAP's answers #### [@cap-js-community/common](https://onedevatlas.dev/cap/artifacts/cap-js-community-common) - Record: https://onedevatlas.dev/cap/artifacts/cap-js-community-common.md - Type: package, ecosystem CAP, by a community org - Does here: Replicates a service into tenant-aware SQLite for querying with the original service’s queries; @cds.replicate selects entities and exposes TTL, preload and static replication options. - Stated in: - [CAP Node.js Community Common — Replication Cache](https://github.com/cap-js-community/common/blob/main/README.md), checked 2026-09-17: “The replication cache allows to cache a service (e.g. db service) into a tenant-aware SQLite database.” - Runs on: Node.js - Flavors: Node.js, from its runtimes - Requires: [@cap-js/sqlite](https://onedevatlas.dev/artifacts/cap-js-sqlite), Replication cache requires [@cap-js/sqlite](https://onedevatlas.dev/artifacts/cap-js-sqlite) as a production dependency, not only a development dependency. - Licence: Apache-2.0, crawled 2026-10-24 - Latest release: 0.5.5, 2026-10-22 - Repository: last push 2026-10-22 - Readings (crawled 2026-10-24): Maintenance good, released this month; Continuity good, 7 contributors, 6 publishers, org-owned; Repository good, pushed 2026-10, not archived - Use cases: Cache a remote service response: Not assessed; Cache the result of a function call: Not assessed; Keep a cached result from reaching the wrong tenant, user or locale: Covers, under conditions; Refresh cached reads after a write: Covers; Serve repeated reads of a rarely written entity from a cache: Covers; Share one cache across application instances: Not assessed; Skip resending a record the client already has: Not assessed; Tell a client how long a served file stays fresh: Not assessed - Caching layer: Service data replicated into local SQLite (“Local replicated SQLite database can be queried with same query as the original service.”) - Freshness control: TTL, tags and optional invalidateOnWrite (“`@cds.replicate.ttl: Number`: Time-To-Live (TTL) of cache entry in milliseconds - `@cds.replicate.auto: Boolean`: Replication is managed automatically - `@cds.replicate.preload: Boolean`: Preload replication for entity”) - Tenant partitioning: Tenant-aware replication; static option is non-tenant-aware (“The replication cache allows to cache a service (e.g. db service) into a tenant-aware SQLite database. […] `@cds.replicate.static: Boolean`: Statically replicate non-tenant aware”) - When not to use it: It is a bundle, not a plugin with one job. Depending on it for one feature brings the rest. #### [@sap/cds](https://onedevatlas.dev/cap/artifacts/sap-cds) - Record: https://onedevatlas.dev/cap/artifacts/sap-cds.md - Type: package, ecosystem CAP, by SAP - Does here: Supports ETag-based conditional HTTP reads for annotated entities in the CAP Node.js runtime. - Delivery: built in - Stated in: - [capire — Generic Service Providers](https://cap.cloud.sap/docs/guides/services/served-ootb), checked 2026-09-17: “caching techniques using ETags” - Runs on: Node.js - Flavors: Node.js, from its runtimes - Requires: [@sap-cloud-sdk/http-client](https://onedevatlas.dev/artifacts/sap-cloud-sdk-http-client) (conditional), Resolving destinations that the runtime's own fetch client does not cover; installing it makes the runtime use it instead.; [@sap-cloud-sdk/http-client](https://onedevatlas.dev/artifacts/sap-cloud-sdk-http-client) (conditional), Outgoing remote service calls that need a destination feature the native fetch client does not cover, such as on-premise connectivity or an authentication type beyond basic and client credentials; used by default when it is installed. - Add-ons: [@cap-js/telemetry](https://onedevatlas.dev/artifacts/cap-js-telemetry), [@rizing/cds-extension](https://onedevatlas.dev/artifacts/rizing-cds-extension), [btp-agent](https://onedevatlas.dev/artifacts/lemaiwo-btp-agent), [cap-companion](https://onedevatlas.dev/artifacts/sleibach-cap-companion), [ui5-cap-serverside-rendering-demo](https://onedevatlas.dev/artifacts/lemaiwo-ui5-cap-serverside-rendering-demo) - Licence: SAP DEVELOPER LICENSE AGREEMENT 3.2 CAP, crawled 2026-10-25 - Latest release: 10.2.1, 2026-10-21 - Repository: none - Readings (crawled 2026-10-25): Maintenance good, released this month; Continuity fair, 2 publishers on npm; Repository unknown, no repository data - Use cases: Cache a remote service response: Assessed, not known; Cache the result of a function call: Assessed, not known; Keep a cached result from reaching the wrong tenant, user or locale: Not assessed; Refresh cached reads after a write: Not assessed; Serve repeated reads of a rarely written entity from a cache: Assessed, not known; Share one cache across application instances: Not assessed; Skip resending a record the client already has: Covers; Tell a client how long a served file stays fresh: Stated not supported - Caching layer: HTTP resource validation with ETags (“caching techniques using ETags”) - Freshness control: Conditional GET using If-None-Match; 304 for an unchanged record (“304 Not Modified”) - Does not say: Tenant partitioning #### [cds-caching](https://onedevatlas.dev/cap/artifacts/cds-caching) - Record: https://onedevatlas.dev/cap/artifacts/cds-caching.md - Type: cds-plugin, ecosystem CAP, independently maintained - Does here: Retains query, request and function results, with expiry and optional entity-write invalidation through @cache annotations. - Stated in: - [cds-caching — README](https://github.com/mikezaschka/cds-caching/blob/main/README.md), checked 2026-09-17: “Transparently cache CQN queries, CAP requests, or function calls” - Runs on: Node.js - Flavors: Node.js, from its runtimes - Requires: [@sap/cds](https://onedevatlas.dev/artifacts/sap-cds) (required), Requires [@sap/cds](https://onedevatlas.dev/artifacts/sap-cds) >= 8.; [Redis](https://onedevatlas.dev/externals/redis) (conditional), Cache storage through @keyv/redis; other store modes do not require this backend.; [SQLite](https://onedevatlas.dev/externals/sqlite) (conditional), Cache storage through @resolid/keyv-sqlite or @keyv/sqlite; other store modes do not require this backend.; [PostgreSQL](https://onedevatlas.dev/externals/postgresql) (conditional), Cache storage through @keyv/postgres; other store modes do not require this backend.; [SAP HANA](https://onedevatlas.dev/artifacts/sap-hana) (conditional), Cache storage through keyv-hana; other store modes do not require this backend.; [@cap-js/sqlite](https://onedevatlas.dev/artifacts/cap-js-sqlite) (conditional), The README requirements table specifies ^1 with cds 8, ^2 with cds 9, and ^3 with cds 10. - Connects to: [Redis](https://onedevatlas.dev/externals/redis), data - Licence: MIT, crawled 2026-10-24 - Latest release: 3.1.1, 2026-09-20 - Repository: last push 2026-09-20 - Readings (crawled 2026-10-24): Maintenance good, 1 month since release; Continuity good, 5 contributors, 1 publisher; Repository good, pushed 2026-09, not archived - Use cases: Cache a remote service response: Covers; Cache the result of a function call: Covers; Keep a cached result from reaching the wrong tenant, user or locale: Covers, under conditions; Refresh cached reads after a write: Covers; Serve repeated reads of a rarely written entity from a cache: Covers; Share one cache across application instances: Covers, under conditions; Skip resending a record the client already has: Not assessed; Tell a client how long a served file stays fresh: Not assessed - Caching layer: Read-through results: queries, requests and functions (“Transparently cache CQN queries, CAP requests, or function calls”) - Freshness control: TTL, tags and optional invalidateOnWrite (“Time-based expiry and tag-based invalidation […] When `invalidateOnWrite` is set, the cache for that entity is automatically cleared after any CREATE, UPDATE, or DELETE operation, so subsequent reads always return fresh data.”) - Tenant partitioning: Automatic tenant-aware keys in MTX; explicit opt-out available (“`isTenantAware` is automatically set to `true` in MTX mode.”) - When not to use it: When user-dependent responses are cached without user-aware or explicit operation keys, or translated responses share keys across locales. These cases require key isolation; locale-aware keys are off by default. #### [cds-data-federation](https://onedevatlas.dev/cap/artifacts/mikezaschka-cds-data-federation) - Record: https://onedevatlas.dev/cap/artifacts/mikezaschka-cds-data-federation.md - Type: cds-plugin, ecosystem CAP, independently maintained - Does here: Caches federated responses through [cds-caching](https://onedevatlas.dev/artifacts/cds-caching), or retains entity snapshots through [cds-data-pipeline](https://onedevatlas.dev/artifacts/mikezaschka-cds-data-pipeline). Writable delegates require manual invalidation or a shorter TTL. - Stated in: - [cds-data-federation — Caching Federated Entities](https://mikezaschka.github.io/cds-data/federation/integration/caching.html), checked 2026-09-17: “cache.strategy: 'response' (default)” - [cds-data-federation — Caching Federated Entities](https://mikezaschka.github.io/cds-data/federation/integration/caching.html), checked 2026-09-17: “For writable delegates, neither cache strategy auto-invalidates on CUD — plan manual invalidation or shorter TTL.” - Runs on: Node.js - Flavors: Node.js (“The plugin auto-activates on load via `cds-plugin.js`.”) - CAP version: >=9 - Requires: [cds-caching](https://onedevatlas.dev/artifacts/cds-caching), For response caching.; [cds-data-pipeline](https://onedevatlas.dev/artifacts/mikezaschka-cds-data-pipeline), For entity caching and replication.; [@cap-js/sqlite](https://onedevatlas.dev/artifacts/cap-js-sqlite), For the entity-cache strategy. - Licence: MIT, crawled 2026-10-26 - Latest release: 0.4.0, 2026-09-20 - Repository: last push 2026-09-22 - Readings (crawled 2026-10-26): Maintenance good, 1 month since release; Continuity fair, 2 contributors, 1 publisher; Repository good, pushed 2026-09, not archived - Use cases: Cache a remote service response: Covers, under conditions; Cache the result of a function call: Not assessed; Keep a cached result from reaching the wrong tenant, user or locale: Not assessed; Refresh cached reads after a write: Stated not supported; Serve repeated reads of a rarely written entity from a cache: Not assessed; Share one cache across application instances: Not assessed; Skip resending a record the client already has: Not assessed; Tell a client how long a served file stays fresh: Not assessed - Caching layer: Federated responses or whole-entity snapshots (“cache.strategy: 'entity' — built into cds-data-federation; stores a full remote projection snapshot in secondary SQLite via cds-data-pipeline, then satisfies arbitrary READ CQNs from SQLite until TTL.”) - Freshness control: Response: tags/TTL; entity: TTL and reload on miss; no automatic CUD invalidation (“For writable delegates, neither cache strategy auto-invalidates on CUD — plan manual invalidation or shorter TTL.”) - Does not say: Tenant partitioning ### BTP/BAIP's answers #### [Redis on SAP BTP, hyperscaler option](https://onedevatlas.dev/btp/artifacts/btp-redis) - Record: https://onedevatlas.dev/btp/artifacts/btp-redis.md - Type: service, ecosystem BTP/BAIP, by SAP - Does here: Provides [Redis](https://onedevatlas.dev/externals/redis) cache instances, with separate development and production-ready plans. - Stated in: - [SAP BTP service metadata — Redis](https://github.com/SAP-samples/btp-service-metadata/blob/main/v1/developer/redis-cache.json), checked 2026-09-17: “Create production-ready Redis Cache instances with premium features.” - Runs on: does not say - Requires: nothing stated - Licence: not stated - Readings (crawled 2026-10-24): Deprecation good, no plan deprecated, 5 plans; Beta good, no plan in beta - Use cases: Cache a remote service response: Not assessed; Cache the result of a function call: Not assessed; Keep a cached result from reaching the wrong tenant, user or locale: Not assessed; Refresh cached reads after a write: Not assessed; Serve repeated reads of a rarely written entity from a cache: Not assessed; Share one cache across application instances: Covers; Skip resending a record the client already has: Not assessed; Tell a client how long a served file stays fresh: Not assessed ### ABAP's answers #### [ABAP-CACHE-BOX](https://onedevatlas.dev/abap/artifacts/furkancosgun-abap-cache-box) - Record: https://onedevatlas.dev/abap/artifacts/furkancosgun-abap-cache-box.md - Type: generator, ecosystem ABAP, independently maintained - Does here: Generates a singleton ABAP cache class, with put, get, delete, clear and size, for a given data type or object reference. - Stated in: - [furkancosgun/ABAP-CACHE-BOX — README](https://github.com/furkancosgun/ABAP-CACHE-BOX), checked 2026-09-14: “This repository provides a flexible and reusable ABAP cache implementation using macros.” - Runs on: does not say - Flavors: does not say - Requires: nothing stated - Licence: MIT, crawled 2026-10-26 - Latest release: no release read - Repository: last push 2024-08-20 - Readings (crawled 2026-10-26): Maintenance unknown, no release data; Continuity fair, one contributor, personally owned; Repository poor, pushed 2024-08, not archived - Use cases: Cache a remote service response: Not assessed; Cache the result of a function call: Not assessed; Keep a cached result from reaching the wrong tenant, user or locale: Not assessed; Refresh cached reads after a write: Not assessed; Serve repeated reads of a rarely written entity from a cache: Not assessed; Share one cache across application instances: Not assessed; Skip resending a record the client already has: Not assessed; Tell a client how long a served file stays fresh: Not assessed ## Comparison What each artifact states for the facets this capability declares, with the sentence it rests on listed under the artifact above. Rows are alphabetical; nothing is ranked. | Artifact | Caching layer | Freshness control | Tenant partitioning | |---|---|---|---| | [@cap-js-community/common](https://onedevatlas.dev/cap/artifacts/cap-js-community-common) | Service data replicated into local SQLite | TTL, tags and optional invalidateOnWrite | Tenant-aware replication; static option is non-tenant-aware | | [@sap/cds](https://onedevatlas.dev/cap/artifacts/sap-cds) | HTTP resource validation with ETags | Conditional GET using If-None-Match; 304 for an unchanged record | does not say | | [cds-caching](https://onedevatlas.dev/cap/artifacts/cds-caching) | Read-through results: queries, requests and functions | TTL, tags and optional invalidateOnWrite | Automatic tenant-aware keys in MTX; explicit opt-out available | | [cds-data-federation](https://onedevatlas.dev/cap/artifacts/mikezaschka-cds-data-federation) | Federated responses or whole-entity snapshots | Response: tags/TTL; entity: TTL and reload on miss; no automatic CUD invalidation | does not say | | [Redis on SAP BTP, hyperscaler option](https://onedevatlas.dev/cap/artifacts/btp-redis) | Redis cache service | does not say | does not say | ## Learn more ### About Caching - [Performance Boost and Caching Strategy for Faster Data Access using "cds-caching" in SAP CAP](https://community.sap.com/t5/technology-blog-posts-by-members/performance-boost-and-caching-strategy-for-faster-data-access-using-quot/ba-p/14031045), 2025-03-04, blog, record https://onedevatlas.dev/content/performance-boost-and-caching-strategy-with-cds-caching.md ### About cds-caching - [CAP just got faster: What's new in cds-caching 1.0](https://community.sap.com/t5/technology-blog-posts-by-members/cap-just-got-faster-what-s-new-in-cds-caching-1-0/ba-p/14152848), 2025-07-15, blog, record https://onedevatlas.dev/content/cap-just-got-faster-whats-new-in-cds-caching-1-0.md - [Boosting performance in SAP Cloud Application Programming Model (CAP) applications with cds-caching](https://community.sap.com/t5/technology-blog-posts-by-members/boosting-performance-in-sap-cloud-application-programming-model-cap/ba-p/14002015), 2025-06-25, blog, record https://onedevatlas.dev/content/boosting-performance-in-cap-with-cds-caching.md - [Performance Boost and Caching Strategy for Faster Data Access using "cds-caching" in SAP CAP](https://community.sap.com/t5/technology-blog-posts-by-members/performance-boost-and-caching-strategy-for-faster-data-access-using-quot/ba-p/14031045), 2025-03-04, blog, record https://onedevatlas.dev/content/performance-boost-and-caching-strategy-with-cds-caching.md ### About cds-data-federation - [Federating, Replicating, and Caching Remote Data in CAP — Part 2](https://community.sap.com/t5/technology-blog-posts-by-members/federating-replicating-and-caching-remote-data-in-cap-part-2/ba-p/14442604), 2026-07-17, blog, record https://onedevatlas.dev/content/federating-replicating-and-caching-remote-data-in-cap-part-2.md - [The Full Picture: Federating, Replicating, and Caching Remote Data in CAP — Part 1](https://community.sap.com/t5/technology-blog-posts-by-members/federating-replicating-and-caching-remote-data-in-cap-part-1/ba-p/14402349), blog, record https://onedevatlas.dev/content/federating-replicating-and-caching-remote-data-in-cap-part-1.md ### Topic editions naming these artifacts - [Building onedevatlas](https://onedevatlas.dev/topics/building-onedevatlas), edition 1, 2026-10-25 ## Vocabulary - Coverage: - SAP and community: SAP's own and at least one community or independent artifact are mapped here. - SAP only: the artifacts mapped here are SAP's own. - Origin: - by SAP: Published by SAP itself. A visible facet, never an input to a reading — a dormant official plugin reads exactly like a dormant independent one. - by a community org: Published by a community organisation, so it outlives any one maintainer. - independently maintained: Published by one person or a small company outside SAP. Says nothing about quality; the readings say that. - Type: - service: A BTP service you subscribe to and bind, rather than install. It has plans and regions, not versions, and may deliver a product that lives outside the atlas. - package: A library you install and call yourself. - cds-plugin: Installs into a CAP project and extends the runtime. CAP loads it through cds.requires or the plugin hook. - generator: Creates a project, a component or configuration once, when you run it, rather than taking part in every build. - Flavor: - Node.js: CAP on Node.js: @sap/cds and the plugins that load into it. - Delivery: - built in: the runtime serves it; nothing to install. - Use-case answers: - Shown working: an attached content item shows the outcome working with this artifact. - Covers: a contribution the sources document. - Covers, under conditions: a contribution documented when named prerequisites hold. - Likely, from its properties: nobody assessed it, and it states every property the use case needs. - Stated not supported: a source rules out the exact outcome. - Assessed, not known: assessed; the sources do not establish it either way. - Not assessed: the assessment does not name it. - Dates: - assessed: the day a person assessed the coverage or the use case and wrote it down. - checked: the day a person opened the cited source and confirmed the quoted sentence was there. - crawled: the day a script read the registry, the repository or the catalogue for the readings. - generated: the day this record was produced from the graph.