db-multitenancy

db-multitenancy is a skill for Claude Code from Hainrixz/claude-db. It costs 81 tokens per session (1,136 once invoked), scanned A, original, MIT.

A review tool for checking whether a multi-tenant database keeps each customer’s data separate. Multi-tenancy means one application serves multiple customers while storing their data in the same system or related systems.

In plain words
What is it for?
Use it to review tenant models, customer-owned tables, access rules, database constraints, and indexes for cross-customer data leaks and inefficient lookups.
Why use it?
It helps find database designs and queries that could expose one customer’s data to another. It also checks whether tenant filtering is consistently enforced and supported by database keys and indexes.

Skill for Claude Code

Written for Claude Code: allowed-tools in frontmatter.

Part of the claude-db plugin — 36 skills, 6 agents, 1 hook shipped together

Good fit Use it to review tenant models, customer-owned tables, access rules, database constraints, and indexes for cross-customer data leaks and inefficient lookups.

Compare 6 skills from other repositories ↓
Install with agentmods
npx agentmods add skills/hainrixz/claude-db/db-multitenancy
Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

Any agent
npx skills add Hainrixz/claude-db --skill db-multitenancy
Clone the repo
git clone --depth 1 https://github.com/Hainrixz/claude-db

Made for: Claude Code.

Or install claude-db, the plugin that ships this one along with the rest of its 36 skills, 6 agents, 1 hook.

Wrote this? Show the measurements

A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.

agentmods badge for db-multitenancy

README.md
[![agentmods](https://agentmods.dev/badge/skills/hainrixz/claude-db/db-multitenancy.svg)](https://agentmods.dev/skills/hainrixz/claude-db/db-multitenancy)
Your own site
<a href="https://agentmods.dev/skills/hainrixz/claude-db/db-multitenancy"><img src="https://agentmods.dev/badge/skills/hainrixz/claude-db/db-multitenancy.svg" alt="Measured on agentmods" height="20"></a>
Per session 81 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 1,136 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. A grade says what 26 rules found in the file — not that it is safe.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5.1 $0.00081 $0.01136
Opus 5 $0.00041 $0.00568
Sonnet 5 $0.00016 $0.00227
Haiku 4.5 $0.00008 $0.00114

Measured 7d ago against content hash 338ecfe7e719, method: parsed. Prices are Anthropic first-party input rates as of 2026-09-07, from the pricing page.

Security

Grade A, and why

db-multitenancy scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 7d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

skills/db-multitenancy/SKILL.md · 52 lines

How it starts

The opening of the file, as written. The whole thing — 52 lines — stays where its author put it; the contents beside it link to each section on GitHub.

db-multitenancy (M9)

In a multi-tenant system the tenant boundary is the most important constraint in the schema: a single query that forgets it leaks one customer's data to another. It is also a performance axis — tenant_id must lead the keys and indexes so every access is tenant-pruned. This module is both-axis: isolation on design (Seguridad), index/partition locality on performance (Escala). Skip entirely (not_applicable) when the system is single-tenant.

What it checks

  • Tenant model fit: shared-table (tenant_id column) vs schema-per-tenant vs database-per-tenant — flag a model mismatched to the isolation requirement (e.g. shared rows for a strict-isolation/regulated workload with no RLS).
  • Missing tenant scoping: tenant-owned tables lacking a tenant_id/org_id/account_id column, or a tenant column that is nullable (allowing un-scoped rows).
  • Unenforced isolation: tenant scoping relied on app code only, with no RLS policy (Postgres) and no constraint — one missing WHERE tenant_id = ? leaks data. Ties to M10 (RLS off = sev5 on a relied-on tenant table).
  • tenant_id-leading index/key: indexes and the PK/clustering key that do not lead with tenant_id, so the engine cannot prune to one tenant — full-table scans crossing tenants (perf) and worse isolation. Ties to M11 ESR ordering and M16 partitioning.
  • Cross-tenant FK / UNIQUE: uniqueness or FKs defined without the tenant column, allowing collisions/joins across tenants.

Axis & severity

  • RLS off / no enforced isolation on a relied-on shared-tenant table: severity 5, fail, axis both, confidence established (caps; the cap itself is owned/asserted with M10's RLS rule — coordinate, do not double-count).
  • Tenant-owned table missing tenant_id: severity 4, warn/fail, axis both.
  • Index/PK not leading with tenant_id: severity 3, warn, axis performance.
  • UNIQUE/FK omitting tenant column: severity 3–4, warn, axis both.

Tier-0 static check

Parse DDL/snapshot via scripts/parse-schema.mjs: identify tenant-owned tables (heuristic: business tables in a system flagged multi-tenant), check each for a non-null tenant column, verify PKs/UNIQUEs/indexes lead with it, and detect declared RLS policies. Program-source parses stay directional and never raise the sev-5 cap.

Read the full file on GitHub · 52 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 7d ago First seen · 52 lines · 81 tokens per session scan A 338ecfe7e719

Subscribe to this mod's changes

db-multitenancy is a skill published in the GitHub repository Hainrixz/claude-db (19 stars, last pushed 2mo ago), licensed MIT. It adds 81 tokens to every session and 1,136 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.

Related

Other skills, from other repositories

dynamodb

Use when modeling or operating a DynamoDB table: deriving partition/sort keys from access patterns, single-table vs table-per-entity, adding a GSI/LSI, on-demand vs provisioned capacity, or diagnosing hot-partition throttling. NOT relational schema/SQL/EXPLAIN (that is postgresdb), NOT aggregation-pipeline document…

ericrisco/rsc-harness · 82 tokens

malloy-lookml-review

Analyze LookML files as prior art for Malloy modeling. Used during Step 1 (DISCOVER) when .lkml files are present. Coordinates reference files that extract business logic, relationships, and curation decisions. Works with or without a database connection.

malloydata/publisher · 58 tokens

convex-migrations

Schema migration strategies for evolving applications including adding new fields, backfilling data, removing deprecated fields, index migrations, and zero-downtime migration patterns.

waynesutton/convexskills · 35 tokens

database-design-patterns

Database schema design patterns and optimization strategies for relational and NoSQL databases. Use when designing database schemas, optimizing query performance, or implementing data persistence layers at scale.

NickCrew/Claude-Cortex · 37 tokens

database-sql

Design database schemas, write efficient SQL queries, create migrations, and optimize database performance. Use when working with databases, writing queries, or designing data models.

asgarovf/locusai · 35 tokens

data-design

Data modeling, schema design, and data architecture.

miles990/claude-software-skills · 12 tokens