ADR-0010 — repo_name = schema_name (db_name for multi-tenant)

Update date : 2026-05-27 21:55

Status: accepted Date: 2026-05-27

Context

The provider needs to know the target schema at deploy time. Without a convention, this requires explicit configuration in every repo. With a convention, it is derivable from the repo name.

Decision

Standard case: repo_name = schema_name

One repo deploys to exactly one schema. The provider derives the target schema from the repo name — no explicit schema declaration needed in manifest.yml.

Multi-tenant case (Pluto products): repo_name = db_name

db_name follows {TYPE}__{WHAT} — everything derives from the name:

Derived value	Rule	Example (DATA_PRODUCT__PLUTO_MATCH)
TYPE	split(db_name, '__')[0]	DATA_PRODUCT
WHAT	split(db_name, '__')[1]	PLUTO_MATCH
schema_provider	always PUBLIC	PUBLIC
STREAMLIT_APP_NAME	PUBLIC.APP__{WHAT}	PUBLIC.APP__PLUTO_MATCH
DAG	{CLIENT_SCHEMA}.{WHAT}	CLIENT_A.PLUTO_MATCH

The provider deploys to PUBLIC only. Client schemas (CLIENT_A, CLIENT_B…) are provisioned by PROVISION_CLIENT() SP — outside the provider's scope.

Consequences

• CI/CD derives the target schema from the repo name automatically — zero per-repo config.
• The registry tables, stage paths (external_input_files/{schema_name}/), and pinkysight monitoring all resolve from the same source: the repo name.
• Renaming a repo = renaming the schema. This is intentionally rare and treated as a breaking change.
• The convention is enforced by the suite naming rules, not by the provider — the provider trusts it.