What is the difference between row-level security, schema-per-tenant, and database-per-tenant multi-tenancy?

Row-level security (shared database, shared schema with a tenant_id column) keeps all tenants' data in the same tables, separated by a filter applied at the application layer or database policy level. It is the cheapest to operate and fastest to build, but offers the weakest isolation guarantee: a bug in the query layer or a misconfigured policy can expose data across tenants. Schema-per-tenant gives each tenant their own set of tables within a shared database instance; it allows per-tenant schema evolution and provides stronger logical isolation than row-level separation, but requires schema provisioning for each new customer and becomes operationally expensive at thousands of tenants. Database-per-tenant gives each tenant a dedicated database instance with its own connection pool, storage, and backup configuration; it provides the strongest isolation, supports per-tenant data residency routing and independent restore, and is the model most enterprise prospects expect, but has the highest operational overhead per tenant. The three models sit on a spectrum from simplest-to-build to strongest-isolation, and the choice determines what the product can and cannot promise to a prospect's security team.

Why does the multi-tenancy isolation model constrain enterprise sales deals?

Enterprise security questionnaires routinely ask: Can our data live in a dedicated database? Can data residency be configured to a specific region? Can a single tenant's data be restored independently without touching other tenants' data? Can you provide database-level isolation for our SOC 2 / ISO 27001 / HIPAA review? Each of these questions has an answer that depends directly on the isolation model. A team with row-level security can offer logical isolation at the application layer, but cannot offer per-tenant database restore, per-tenant regional routing, or dedicated database instances without a significant migration. A team with database-per-tenant can answer yes to all of these as a standard configuration. The gap between what the sales team wants to promise and what the isolation model supports is where the undocumented multi-tenancy decision becomes an enterprise sales blocker — and the decision is hardest to change precisely when the first enterprise deal is in progress, because the team is under pressure to promise a timeline rather than acknowledge an architectural constraint.

What should a multi-tenancy ADR include?

A multi-tenancy ADR should include: the context describing the current customer scale (number of tenants, size distribution, cross-tenant query volume) and the enterprise sales motion (whether dedicated instances are an active requirement or a future consideration); the alternatives evaluated (shared-database-with-tenant-id, schema-per-tenant, database-per-tenant) with specific trade-offs for each at the team's current scale and compliance posture; the decision naming the chosen isolation model with the operational, security, and compliance rationale; the data residency policy (whether tenants can request specific regional hosting and what the isolation model enables); the compliance certification scope (which certifications the isolation model supports — SOC 2, ISO 27001, HIPAA BAA, FedRAMP — and what the dedicated-instance path looks like for certifications the current model cannot support); and a revisitation condition that names the triggers for re-evaluation — most commonly, an enterprise prospect requiring a higher isolation level, a compliance certification requiring database-level isolation, or a customer count or tenant size that changes the operational trade-offs.

How do you find multi-tenancy decisions in AI chat history?

Multi-tenancy isolation decisions appear in AI chat at three predictable points: early database design sessions ('how do I separate data per customer in Postgres?', 'should I use a tenant_id column or separate schemas?', 'how does row-level security work?'), security review sessions that precede a SOC 2 audit or enterprise security questionnaire ('is there any risk of cross-tenant data leaks?', 'what should I put in the security questionnaire about data isolation?'), and enterprise deal sessions where the gap between the isolation model and the prospect's requirements becomes explicit ('the customer wants a dedicated database — how hard would that migration be?', 'can we support data residency in the EU for this deal?'). The enterprise deal sessions are the highest-value extraction targets because they contain the first honest gap analysis between the current isolation model and enterprise requirements — the information that should have been in the ADR from the beginning. The WhyChose extractor identifies these sessions through the multi-tenancy vocabulary (tenant_id, row-level security, schema-per-tenant, database-per-tenant, data residency, dedicated instance, cross-tenant, isolation) and the enterprise sales vocabulary (security questionnaire, SOC 2, HIPAA BAA, dedicated database, data residency, FedRAMP).

2026-06-14 · ~16 min read

The multi-tenancy decision record: why the isolation model you chose in year one constrains every enterprise deal in year three

Every SaaS product has a multi-tenancy isolation model. Most chose it implicitly: a tenant_id column added during the product's first week because it was the simplest way to separate customer data when there was only one paying customer and the question of tenant isolation felt theoretical. The question did not feel theoretical when the first enterprise prospect submitted a security questionnaire asking whether their data could live in a dedicated database in Germany, audited quarterly, accessible only to their own security team. The answer to that question was determined by an architectural decision made years earlier, without documentation, without deliberation, and without any accounting for what it would cost to change.

The multi-tenancy isolation model is unique among architectural decisions in that its consequences are not felt by engineering — they are felt by the sales team. The caching strategy that performs poorly slows the product for everyone. The API versioning decision that lacked a breaking-change definition creates engineering coordination costs on every release. But the isolation model that cannot support dedicated database instances does not create any visible engineering problem at all: the product works correctly, the data is separated correctly, and every customer gets the data they expect. The problem surfaces only when a prospective customer asks for a capability that the isolation model was never designed to provide. By that point, the architectural decision is three years old, entrenched in 47 tables, injected by the ORM middleware, segmented by the analytics pipeline, and billed by the billing system. It is not possible to change it quickly enough to close the deal it is blocking.

This is the particular cost of undocumented multi-tenancy decisions: they are invisible until the moment they become the most expensive architectural constraint the team has. And that moment always arrives under pressure — not in a quiet architectural review session but in a sales cycle with a named enterprise account, a committed timeline, and a procurement team waiting on the security team's approval.

Why "shared database with tenant_id" is a decision, not a default

The shared database with row-level separation is the de facto starting point for SaaS multi-tenancy not because engineering teams evaluate isolation models and select it, but because it is the path of least resistance. An engineer building the first version of a product adds a tenant_id column on the first table because the product will eventually have multiple customers. This is how they have seen it done in tutorials, in open-source projects, in the codebases they have worked on before. The decision is made at the schema level, in a migration file, without a written evaluation of whether this is the right model for the product's likely customer profile and compliance trajectory. The migration file does not say: "We are choosing shared-database-with-RLS over schema-per-tenant and database-per-tenant because we have one customer and the operational overhead of schema provisioning is not justified at this scale, and we will revisit this decision if an enterprise prospect requires database-level isolation." It says: ALTER TABLE users ADD COLUMN tenant_id INTEGER NOT NULL.

The claim that "we use row-level security for tenant isolation" is a real architectural claim with specific consequences. It claims that the application layer correctly filters all queries on tenant_id. It claims that a misconfigured query or a bug in the ORM middleware will not expose one tenant's data to another. It claims that the team's SOC 2 controls for logical separation are implemented at the application layer rather than the database layer. It claims that per-tenant restore requires extracting rows from a full backup rather than restoring a dedicated instance. It claims that data residency routing would require a regional deployment rather than a per-tenant database configuration. None of these consequences were chosen; they were accepted by default when the team chose the simplest isolation model without writing down what they were and were not committing to.

The "we'll figure out enterprise isolation later" decision is not a deferral — it is a claim: that the team's current customer profile does not require database-level isolation, and that the team will recognize when the customer profile changes. The second half of this claim is the part that is never documented. What is the signal that the customer profile has changed? Is it the first security questionnaire that asks about dedicated instances? Is it a compliance certification that requires database-level controls? Is it a deal size threshold above which the isolation model becomes a sales blocker? Without a documented trigger condition, the team relies on the shared recognition that "now" is when the isolation model has become a constraint — a recognition that is hardest to reach when the first enterprise deal is already in the pipeline.

Three categories of multi-tenancy decisions

The multi-tenancy strategy for a system is not a single decision — it is a set of related decisions, usually made at different times, by different people, under different pressures. The isolation model constrains the product team, the infrastructure team, the security team, and the sales team in ways that are not visible from any single team's perspective. The complete multi-tenancy ADR covers all three categories.

The isolation model. Row-level separation (shared database, shared schema, tenant_id filter at the application or database policy layer), schema-per-tenant (shared database instance, separate schema per tenant, each schema containing the full table set), or database-per-tenant (separate database instance per tenant, separate connection string, separate backup and restore scope). The isolation model determines: the blast radius of a cross-tenant data leak (in row-level separation, a misconfigured query exposes data across all tenants in the table; in database-per-tenant, a misconfigured connection string connects to one other tenant's database, not to the entire table); the operational model for new tenant provisioning (in schema-per-tenant, provisioning creates a schema and runs migrations; in database-per-tenant, provisioning creates a database instance with all the associated infrastructure management); the per-tenant backup and restore capability (in row-level separation, restoring a single tenant requires row-level extraction from a full backup; in database-per-tenant, restoring a single tenant is a standard database restore of that tenant's instance); and the enterprise sales motion (whether dedicated-instance requests can be satisfied as a configuration option or require a multi-month migration project).

The isolation model is also the primary determinant of what the compliance team can demonstrate in a SOC 2 audit. The threat model for cross-tenant data exposure differs significantly across isolation models: in row-level separation, the threat requires a query-layer failure; in schema-per-tenant, a schema-routing failure; in database-per-tenant, a connection-pool routing failure. The controls that the team can demonstrate to an auditor depend on which of these failure modes is the relevant one. A team with row-level separation can demonstrate application-layer controls. A team with database-per-tenant can demonstrate database-layer controls that are independent of application code — which is what some enterprise compliance teams require before signing a purchase order.

The data residency decision. Which regions can tenant data live in? What happens when an enterprise deal requires that all data for users in France must be stored on servers in the EU? The data residency decision is usually not made at all — the product runs on a single-region deployment because that is what the infrastructure team set up, and the region was chosen based on where the founders live or where the hosting provider's default is. "Single region, US East" is a data residency policy: it means that all tenant data, regardless of customer location, is stored in one region. This policy has compliance consequences for European customers under GDPR Article 44 (restrictions on transfers to third countries without adequacy decisions or appropriate safeguards), for US government customers under FedRAMP (which requires US-only hosting and specific access controls), and for healthcare customers under HIPAA (which does not mandate US-only hosting but intersects with Business Associate Agreements in ways that require the hosting location to be disclosed).

The data residency decision is constrained by the isolation model in a way that makes the two decisions inseparable. A shared-database system can add regional routing — a European deployment for European tenants, a US deployment for US tenants — but the routing must be determined at account creation time and cannot be changed after data exists in the original region without a migration. A database-per-tenant system enables per-tenant regional routing as a configuration decision, but requires the team to operate database infrastructure in each supported region. The infrastructure supporting tenant isolation is itself an architectural decision that belongs in the ADR: "We operate in one region today. To support per-tenant data residency, we would need to deploy database infrastructure in each additional region and build routing logic at the account creation step. The isolation model we are choosing now should make this migration possible without a schema rewrite."

The compliance certification scope. What certifications does the team hold or plan to obtain, and what does the isolation model need to support for those certifications? SOC 2 Type II requires demonstrating logical isolation between tenants; row-level separation with demonstrably correct RLS implementation satisfies this for most auditors. ISO 27001 requires an information security management system that documents how tenant data is protected; the isolation model must appear in the asset inventory and the risk assessment. HIPAA requires a Business Associate Agreement with all vendors that handle Protected Health Information; the isolation model determines which vendors need to sign BAAs (a shared-database system requires the database hosting provider to sign a BAA; the team must confirm the provider offers this). FedRAMP Moderate or High requires US-only infrastructure and specific encryption and access control standards that generally require dedicated infrastructure per agency customer. Each certification tier is effectively an isolation model requirement in disguise: the certification that the team pursues commits them to an isolation model capable of satisfying it.

The compliance scope decision is the most consequential silent constraint on the enterprise sales motion. A sales team that closes a HIPAA-covered healthcare customer without the engineering team having decided what the HIPAA-compliant isolation model looks like is creating a commitment that engineering must fulfill under a timeline determined by the customer contract, not by the engineering team's roadmap. The platform team that builds tenant isolation infrastructure without a documented compliance scope will build infrastructure that satisfies some certifications and not others — and the gap will be discovered when the first customer in the uncovered certification tier asks for the BAA.

The "default" pathology: how isolation models calcify

The calcification of an isolation model follows a predictable sequence across SaaS products. Understanding the sequence is useful because the teams in it usually do not recognize where they are until they are in Phase 3.

Phase 1: The product launches with shared-database-per-tenant-id. This is the correct choice for a startup with fewer than one hundred customers: fast to build, cheap to operate, easy to debug, sufficient for the workload. The choice is not documented because it is the obvious thing to do and no alternative was seriously evaluated. The migration file adds the column. The application layer injects the filter. The product ships.

Phase 2: Row-level security is added when a security engineer on the team reviews the schema, or when a seed-round investor's security questionnaire asks about cross-tenant data isolation. The RLS policy is added in a migration. The commit message says "add row-level security for tenant isolation." The decision to continue with shared-database-per-tenant rather than migrating to schema-per-tenant or database-per-tenant — which is the real architectural decision, the one with downstream sales consequences — is documented nowhere. The team believes the isolation problem is now solved; the RLS policy is the solution. What they have actually done is implemented a control within an isolation model they have not evaluated.

Phase 3: An enterprise prospect submits a security questionnaire. Question 14 asks: "Do you provide dedicated database instances for enterprise customers?" The sales team forwards the question to engineering. Engineering says: "We use row-level security. A dedicated database instance would require a significant migration." The sales team loses the deal, or negotiates a "custom enterprise deployment" promise on a timeline that engineering must now deliver against.

Phase 4: Engineering evaluates the migration. The evaluation reveals that 47 tables carry tenant_id, that the ORM middleware injects the filter on every query, that the analytics pipeline segments on it, and that the migration to database-per-tenant would require rewriting every query, migrating every table, rebuilding the provisioning system, and validating every feature in the new isolation model. The evaluation also reveals — too late — that the team could have built a routing abstraction at the start that would have made the migration significantly cheaper: not database-per-tenant from day one, but a provisioning layer that decoupled tenant routing from the query layer, so that the underlying storage model could change without rewriting the application.

Phase 5: The team decides to support enterprise customers on a parallel "enterprise deployment" track — a separate configuration of the same product, deployed per customer, with its own database. This is operationally expensive: each enterprise customer requires its own deployment, its own migration pipeline, its own monitoring configuration, and its own upgrade cycle. The first three enterprise customers on this track are manageable. By the time there are fifteen, the engineering overhead of maintaining divergent deployments has become a significant fraction of the team's capacity. The decision to create a separate enterprise deployment track should itself be documented as an ADR — it is a new architectural commitment with consequences for every future hiring, infrastructure, and product decision — but at this point the team is moving too fast to document anything.

The enterprise deal as the forcing function

The enterprise security questionnaire is the most reliable signal that the isolation model needs to be documented. Not because every enterprise deal requires database-per-tenant — many do not — but because the questions enterprise security teams ask expose the gap between the isolation model the team has and the one the prospect needs. The gap is most expensive when it is discovered during a sales cycle with a named account and a committed timeline, rather than in an architectural review session at the beginning of the year.

The standard enterprise security questionnaire asks, in various forms: How is tenant data isolated from other tenants at the database layer? What is the blast radius if an engineering error causes a cross-tenant data leak? Can tenant data be restored independently without affecting other tenants? In what region is tenant data stored, and can data residency be configured per tenant? What compliance certifications does the product hold, and is a Business Associate Agreement available? Is there a dedicated deployment option, and what is the additional cost?

Each of these questions has a deterministic answer that depends on the isolation model. A team with a documented isolation decision can answer from the ADR. A team without documentation must convene an engineering discussion during the sales process to determine the accurate answers — a process that is slow, stressful, and likely to produce answers that are correct for the current implementation but do not reflect any deliberate architectural commitment. The sales team hears these answers as they are being figured out in real time, which is a poor foundation for an enterprise contract.

The enterprise deal forcing function is asymmetric. The team that has documented its isolation model and knows it does not support dedicated instances can tell the sales team clearly and early — before a prospect's time has been invested in the evaluation. The deal either proceeds with the existing isolation model or it does not. The team that has not documented its isolation model does not know how hard it is to support dedicated instances until the sales process is well advanced, at which point the cost of saying no is higher and the temptation to promise a migration timeline is strongest. The new technical leader who inherits a product mid-sales-cycle faces the sharpest version of this: they must determine the isolation model, evaluate the migration cost, and formulate a response to an enterprise prospect's security questionnaire — often within the same week — without any ADR to read and without the engineers who made the original decision available to ask.

Writing the multi-tenancy ADR

The structure of an architecture decision record applies directly to multi-tenancy, with several sections that require specific attention.

Context. The context section should describe the current customer scale (number of tenants, approximate size distribution, cross-tenant query volume per day), the regulatory environment (whether any existing customers are in regulated industries, whether EU data residency is a current or anticipated requirement), and the enterprise sales motion (whether dedicated instances are an active prospect requirement or a future possibility). The context should also record who made the decision and under what constraints: "This decision was made at company formation, before any paying customers, with a team of two engineers building toward an initial launch." This context is what enables a future engineer to evaluate whether the isolation model is still appropriate, rather than assuming it was carefully evaluated at current scale.

Alternatives Considered. The three primary isolation models should each be evaluated with specific trade-offs for the team's context at the time of the decision:

Shared database, shared schema (tenant_id column): lowest operational overhead, supports unlimited tenants without infrastructure changes, requires application-layer RLS to prevent cross-tenant leaks, does not support per-tenant database restore without row extraction, does not support per-tenant data residency without a regional deployment, satisfies SOC 2 logical isolation requirements with demonstrable RLS policy.

Shared database, schema-per-tenant: moderate operational overhead (schema provisioning per new tenant, migration tooling must support per-schema execution), supports per-tenant schema evolution for enterprise customization, allows per-schema independent restore, does not support per-tenant data residency routing without a regional deployment, has practical limits at very high tenant counts (thousands of schemas in a single database instance introduce catalog query overhead and connection multiplexing complexity in most database engines).

Database-per-tenant: highest operational overhead (instance provisioning, separate connection pools, per-tenant migration pipeline, per-tenant backup and restore operations, per-tenant monitoring), strongest isolation guarantee (a misconfigured connection string routes to one tenant's database, not to all tenants' tables simultaneously), supports per-tenant data residency routing as a standard configuration, supports per-tenant independent restore without extracting rows from a shared backup, satisfies the most demanding enterprise security questionnaires and compliance certification requirements.

Decision. The decision section should name the isolation model chosen, the scale and context at the time of the decision, and the explicit trigger condition for re-evaluation: "We are choosing shared-database-with-tenant_id and row-level security because we have three customers and the operational overhead of schema provisioning is not justified at this scale. We will re-evaluate this decision when: (a) an enterprise prospect's security questionnaire explicitly requires database-level isolation and the deal size justifies a migration investment, (b) a compliance certification we are pursuing requires database-layer controls rather than application-layer controls, or (c) customer count exceeds 500 or a single tenant's data volume exceeds 100GB, at which point the shared-database operational model should be re-evaluated for performance and backup scope."

Consequences. The consequences section should make explicit what the chosen isolation model rules out, not just what it enables: "With shared-database-per-tenant-id, we cannot offer per-tenant database restore without row-level extraction from a full backup. We cannot support per-tenant data residency routing without a dedicated regional deployment. We cannot satisfy an enterprise security questionnaire that requires database-level isolation without a migration project whose cost should be estimated at the time of the deal rather than at the time of the questionnaire response. These constraints are acceptable at our current scale and sales motion. The trigger conditions above are the signals that the isolation model needs to change."

Data Residency Section. Named separately from the core isolation model: "We operate in a single region (us-east-1). All tenant data is stored in this region regardless of customer geography. EU data residency requirements under GDPR Article 44 are not currently supported; an EU-only deployment would require operating database infrastructure in an EU region and building account-creation-time routing logic. This is not planned for the current roadmap. Any enterprise sales conversation that involves EU data residency requirements should be flagged to engineering before making commitments." The data residency policy interacts directly with the data retention policy: a GDPR right-to-erasure request must be executed against all regions where the tenant's data exists, which is why the residency scope and the deletion policy should reference each other.

Compliance Scope Section. Named separately from the isolation model and data residency: "The current isolation model (shared-database-with-RLS) supports SOC 2 Type II logical isolation controls with the demonstrably correct RLS policy in our database. It does not support HIPAA BAA without a database-level isolation guarantee from our hosting provider — we should verify whether our hosting provider's shared-database RLS implementation satisfies BAA requirements before selling to healthcare customers. It does not support FedRAMP without a dedicated US-only infrastructure deployment. These certification gaps should be communicated to the sales team as deal-qualification criteria." The multi-tenancy decision belongs in every early-stage SaaS company's first twelve ADRs, written before the first enterprise deal and certainly before the first compliance audit.

Finding multi-tenancy decisions in AI chat history

Multi-tenancy isolation decisions appear in AI chat at three structurally distinct points, each with a different extraction profile.

The first is the database design session in the product's first weeks. Sessions containing "how do I separate data per customer in Postgres," "should I use a tenant_id column or separate schemas," "what's the right way to do multi-tenancy for a SaaS product," or "how does row-level security work" contain the original alternatives evaluation. The decision that emerged from these sessions is often implicit — the engineer implemented the tenant_id pattern because the AI's response described it as the standard approach for a product at this scale, without documenting an explicit evaluation of the trade-offs or the conditions under which the choice would need to change. Extracting these sessions recovers the original context: what scale the product was at, what alternatives were mentioned (even briefly), and what the engineer knew and did not know about isolation model consequences at the time.

The second is the security review session that precedes a SOC 2 audit or an enterprise security questionnaire. Sessions containing "is there any risk of cross-tenant data leaks in our query layer," "how does our row-level security policy prevent cross-tenant access," "what should I write in a security questionnaire about our data isolation model," or "can a compromised session token access another tenant's data" contain the team's first careful evaluation of their isolation model's security properties. These sessions are high-value extraction targets because they represent the moment the team looked closely at an isolation model they had been using without full deliberation and discovered what it can and cannot guarantee. The gap between "we use tenant_id filtering" and "we have a demonstrably correct RLS policy with unit tests for cross-tenant access" is exactly the content that a security ADR should capture — and it is often first articulated in an AI chat session during audit preparation.

The third is the enterprise deal session, where the sales team or engineering team is responding to a prospect's security requirements. Sessions containing "the customer wants to know if we can give them a dedicated database," "how hard would it be to migrate to database-per-tenant for one enterprise customer," "what certifications would we need before we can sign a HIPAA BAA," or "we lost a deal because they needed EU data residency — what would it take to support that?" contain the first honest gap analysis between the current isolation model and the requirements of a specific enterprise account. These sessions are the highest-value extraction targets because they contain not just the reasoning but the revealed consequence: the isolation model that cost the team a deal, and the engineering estimate of what it would take to close that gap. The build-vs-buy decision for enterprise isolation infrastructure — whether to build per-tenant database provisioning in-house or use a managed service that handles it — is often first evaluated in one of these enterprise deal sessions, and the evaluation is the content that should be in an ADR.

The WhyChose extractor identifies multi-tenancy sessions through the isolation vocabulary (tenant_id, row-level security, schema-per-tenant, database-per-tenant, tenant isolation, cross-tenant, dedicated instance, shared database) and the enterprise sales vocabulary (security questionnaire, SOC 2, HIPAA BAA, FedRAMP, data residency, dedicated database, EU data, ISO 27001). Enterprise deal sessions that ended with "we'd need to evaluate that migration" or "we'll need to get back to them on that" are identifiable through the pattern of an enterprise requirement raised without a documented resolution — and these are the sessions where the isolation model's consequences were first made visible, regardless of whether the team wrote them down.

What the multi-tenancy record enables

The multi-tenancy ADR — the one that names the isolation model, the data residency policy, the compliance certification scope, and the trigger conditions for re-evaluation — enables three things that the schema migration and the RLS policy alone do not.

It enables an honest, fast response to an enterprise security questionnaire. An engineer who receives Question 14 ("Do you provide dedicated database instances for enterprise customers?") with the multi-tenancy ADR available can answer accurately: the isolation model is shared-database-with-RLS, dedicated instances are not currently supported without a migration, the estimated migration scope is documented in a separate evaluation, and the sales team was informed of this constraint before the security questionnaire was received. The engineer who answers without an ADR must either approximate ("we use row-level security which provides strong isolation") or escalate ("I need to talk to the team before I can answer that") — both of which are worse than an accurate answer delivered promptly.

It enables the sales team to qualify deals before investing in them. A sales team that knows the isolation model does not support dedicated instances can filter prospects who require dedicated instances at the discovery stage rather than the security questionnaire stage. This is not a loss; it is correct qualification. The deal that the sales team spends four months advancing before discovering a hard architectural blocker costs more than the deal that is correctly qualified at the first call. The multi-tenancy ADR, shared with the sales team in plain language, is the qualification tool that prevents the sales-cycle-ending discovery of architectural constraints.

It enables the migration decision when the trigger condition is met. A team with a documented isolation model knows exactly what they chose, why they chose it, what the trigger conditions are for change, and what the consequences of the current model are for a higher-isolation migration. When the engineering team evaluates the isolation model migration, they are evaluating a known architectural commitment rather than reverse-engineering an implicit one. The ADR tells them what the original scale was when the decision was made, what alternatives were evaluated and rejected, and what the team's stated trigger conditions were — giving the migration evaluation a baseline that is not available from the schema alone.