Serving many tenants from one deployment — onboarding, tenant-isolated data, per-tenant schema deployment and the operational tooling around it. It is decided once, before anything is built, and narrows the artifacts in almost every capability downstream: most sharply in cachingCachingHolding 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.SAP and community, unassessed and anything else holding state in process.
@sap/cds-mtxs Multitenancy, tenant provisioning and model extensibility for CAP.
@sap/cds Isolates tenants at runtime: every service call carries the tenant in its context and the framework connects it to that tenant's database. Provisioning, subscription and per-tenant deployment are @sap/cds-mtxs.
com.sap.cds:cds-feature-mt The CAP Java feature that makes a Maven application multitenant aware: tenant lifecycle events, per-tenant database containers, and the wiring to the Node.js MTX sidecar.
com.sap.cds:cds-services-bom Carries the tenant in the Request Context across every service call and thread, and opens tenant-specific database connections from it. Provisioning and subscription are cds-feature-mt.
Not covered: It stops at the runtime. Day-two operations — inspecting, upgrading and repairing tenants across a landscape — is where cap-js-communitycap-js-communitymaintains 10 entriescommunity org fills in, and that is community-org rather than core.
SaaS ProvisioningSAP Software-as-a-Service Provisioning serviceRegisters a multitenant application so that subaccounts can subscribe to it, and calls the application back on every subscribe and unsubscribe.sap official, btp is the registration: it makes an application subscribable by other subaccounts and calls that application back on every subscribe and unsubscribe. What the callback then has to do is why this capability reads so differently on the two doors.
Present, not yet described.
Not covered: At subscription. The callback is where the work starts — tenant-isolated data and per-tenant schema deployment are the application's, and BTP neither performs nor verifies them.
Every provider behind this door is an SAP BTP service, so core-only is a assessment of the corpus rather than a quote from the core. what_core_does is left empty: no page has been checked that states an intent here, and the services themselves carry their own descriptions and links.
No community artifact is documented here.
Neither the package manifest nor the repository tree declares a licence.
Not as the provider behind a live tenant estate: tenant state is kept in a file-based store for demonstration, and the README's own operations notes say a production implementation should use a reliable database so that state survives restarts.
cds 7 dropped support for the old MTX package outright. @sap/cds-mtx, deprecated since cds 6, stopped running at all; @sap/cds-mtxs became the only supported multitenancy library for anything on cds 7 or later.
Any tutorial or sample that provisions tenants through @sap/cds-mtx. That ran on cds 6; on cds 7 and later the app won't start until it migrates to @sap/cds-mtxs.
The core gained a rewritten multitenancy library, @sap/cds-mtxs, alongside the existing @sap/cds-mtx. Where the old library stored tenant extensions as source files and ran a build on the server on every activation, the new one stores only compiled csn files, runs the build locally before deploy, and drops the separate META-tenant container — tenant metadata now lives beside application data.
capability:multitenancy