Core dataPlatformScale plan (tenant registry)

Multi-Tenant SaaS Backends

Serve many customers from one cluster, each confined to its own keys with ACLs, with a tenant registry that records who belongs where.

tenants per server: 256
key patterns for isolation: ACL
users and quota records: Per tenant

Step 1 of 5

An id, a display name and quota values recorded with the tenant.

Example sessionplaying

# Register a tenant

hotkv> TENANT.CREATE acme "Acme Corp" MAX_MEMORY 1073741824 MAX_KEYS 1000000

An animated walkthrough with real HotKV commands and example replies. Click any step to jump to it.

The problem

Running one cache or data store per customer is expensive and painful to operate, but sharing one means you need strong isolation between customers and a record of which users belong to which customer.

How HotKV handles it

ACL users with key patterns confine each tenant's application to its own key prefix. The tenant registry records which users belong to which tenant, along with quota values. The registry is the same on every node of a cluster.

Step by step

What happens, command by command

01
Register a tenant
An id, a display name and quota values recorded with the tenant.
TENANT.CREATE acme "Acme Corp" MAX_MEMORY 1073741824 MAX_KEYS 1000000
02
Confine its users
The ACL user can only touch keys under acme: and cannot run dangerous commands.
ACL SETUSER acme-app on >s3cret ~acme:* +@all -@dangerous
03
Bind the user to the tenant
The registry records which users belong to which tenant.
TENANT.BIND acme acme-app
04
Isolation in action
acme's app reads its own keys. A read of globex's key is refused by the ACL.
GET globex:billing:plan
05
Read the tenant record
The quota values recorded for the tenant. In this release the usage counters are not filled in by client traffic, so they read 0.
TENANT.STATS acme

Where it fits

Real-world scenarios

B2B SaaS

Each customer's cache and session data lives under its own prefix on a shared cluster, isolated by ACL.

Agencies and resellers

Client projects are tenants with their own users, so access can be granted and revoked per client.

Built in

What you get

Key-pattern isolation

ACL users limited to a key prefix and a command set.

ACL SETUSER

Tenant registry

Tenants with names, states, quota values and bound users, the same on every node.

TENANT.CREATETENANT.BIND

Tenant records

Each tenant's name, state, quota values and bound users.

TENANT.INFOTENANT.STATS

Lock a tenant out

Turn the tenant's ACL users off.

ACL SETUSER off

Reference:TENANT.CREATE TENANT.BIND TENANT.STATS ACL SETUSER

Common questions

Are the quota values enforced?

No. They are recorded and shown in TENANT.STATS, but HotKV does not enforce them on commands, and the usage counters are not filled in by client traffic in this release. Isolation comes from ACL rules.

Does suspending a tenant block it?

TENANT.SUSPEND records a state for your tooling. To lock a tenant's users out, turn them off with ACL SETUSER.

Which plans include it?

ACLs work on every plan. The tenant registry is part of the Scale plan.