The same result is displayed in another example when correctly using a tenant id of all twos. A mistake perhaps of wrong output with the wording in the article is all.
For example, you generally only want to have one tenant’s data per storage page. There are many famous ways that interleaving different tenants’ data at a fine-grained level can go very wrong.
There are also advantages from a cache utilization standpoint if the system is heavily loaded.
I understand there are potential regulatory concerns with this, but I've never seen an audit get even remotely close to this level of detail.
So there will be a cost per dB A cost to backup that dB Etc
And so a lot of companies, particularly startup, will keep one large dB.
We're planning to introduce an immutable session variable later this year to make the session-based approach more viable. It won't stop someone from tampering with the tenant_id before it's initially set, but it will prevent any changes afterward. Though in practice, most of our customers aren’t too concerned. They have application-layer guardrails in place and are confident that users can’t tamper with session state directly.
But yes, there are trade offs either way.
When you rug pulled your license, I could not pass.
I'm sure it will be useful to your paying clients, who may be using RLS on their other DBs.
jayzalowitz•7mo ago