PicaJet

Reference Glossary

Single tenant deployment

A DAM deployment where one organization gets its own dedicated software instance and infrastructure, instead of sharing a database and servers with other customers as in multi-tenant SaaS.

Why it matters in a DAM

Regulated buyers — pharma, government contractors, financial services — often need single tenancy to satisfy data residency or audit requirements that a shared multi-tenant environment can't guarantee contractually. It also matters for large agencies running heavy concurrent search and export loads, since a busy neighbor tenant on shared infrastructure can degrade performance in a way single tenancy avoids by design.

A worked example

Data isolation dedicated database/server vs shared schema with row-level separation
Customization deeper — custom network rules, integrations — vs config-only in multi-tenant
Upgrade timing customer-controlled schedule vs vendor pushes to all tenants at once
Typical cost higher infrastructure overhead vs shared economies of scale

Common mistake

Buyers assume "single tenant" automatically means more secure, then skip actually verifying the vendor's specific isolation, encryption-at-rest and patch-management practices — single tenancy isolates infrastructure, it doesn't by itself guarantee a stronger security posture than a well-run multi-tenant SaaS.

Single tenant deployment means one organization’s DAM instance — application, database, storage — runs on infrastructure not shared with any other customer, as opposed to multi-tenant SaaS, where many customers’ data lives in the same underlying systems, logically separated. It’s a deployment and infrastructure decision, not a feature difference in the DAM itself.

It matters most for buyers with contractual or regulatory reasons to keep their data physically or logically separate from other companies’ — a pharmaceutical company under strict audit requirements, or a government agency with data residency rules, often can’t accept a shared-infrastructure answer regardless of how the vendor describes its logical isolation. It also matters operationally: a large in-house creative team running heavy concurrent search, transcoding and export jobs won’t have that load compete with another tenant’s traffic on shared hardware.

The tradeoff is cost and upgrade control. Single tenant instances typically cost more to host and maintain, since there’s no infrastructure sharing across customers, but in exchange the customer usually controls when upgrades and patches roll out, rather than being pushed to a new version on the vendor’s schedule alongside every other tenant.

Buyers should treat single tenancy as a starting point for a security conversation, not the answer to it — the specific encryption, access logging and patch cadence still have to be verified, because dedicated infrastructure that’s poorly maintained is not automatically safer than shared infrastructure that’s maintained well.

Frequently asked

What is single tenant deployment?

One organization's DAM instance -- application, database, storage -- runs on infrastructure not shared with any other customer, as opposed to multi-tenant SaaS where many customers' data lives in the same underlying systems, logically separated.

Who typically needs single tenant deployment?

Regulated buyers like pharma companies under strict audit requirements or government agencies with data residency rules, who often can't accept a shared-infrastructure answer regardless of how the vendor describes its logical isolation.

Does single tenancy automatically mean better security?

No -- buyers should treat it as a starting point for a security conversation, not the answer to it. Dedicated infrastructure that's poorly maintained isn't automatically safer than shared infrastructure that's maintained well; the specific encryption, access logging, and patch cadence still need to be verified.

What operational benefit does single tenancy offer beyond compliance?

A large in-house creative team running heavy concurrent search, transcoding, and export jobs won't have that load compete with another tenant's traffic on shared hardware.

Who controls upgrade timing in a single tenant deployment?

The customer usually controls when upgrades and patches roll out, rather than being pushed to a new version on the vendor's schedule alongside every other tenant, as happens in multi-tenant SaaS.

What's the cost trade-off of single tenant deployment?

It typically costs more to host and maintain, since there's no infrastructure sharing across customers -- the premium buys dedicated infrastructure and upgrade control.