Cell: the dedicated stack is a fortnight

01 · The boundary

You can dedicate the database, the cache, the API and the BFF. You cannot dedicate the identity plane, the vendor quotas or the pipeline, so name that boundary before an auditor finds it

AWS calls the ends of this range silo and pool, and the deliberate mix in between a bridge.1 The part worth holding onto once the decision is already made: AWS still counts a siloed deployment as SaaS only while identity, onboarding, metering and operations stay shared and automated.2 When those fragment too, it stops being a product and becomes a managed-services portfolio.

So the useful artefact is not a tenancy diagram. It is a schedule naming every component as dedicated or shared, agreed before the first cell exists.

Where "completely separate" stops, and why it stops there

Component	Per cell	What it buys, or why it will not split
Database	Dedicated	Its own database on the shared replica set, or its own replica set where the clause says separate server. Roughly 130 dedicated databases fit one set before the namespace guidance bites, so the real ceiling is cache pressure rather than count
Cache	Dedicated	Its own instance and credentials. Cheap, and it closes a whole category of cross-tenant question
API and workers	Dedicated	Its own app carrying both process groups. The platform's own guidance recommends one app per customer, for per-app secrets, regions and network segmentation11 12
BFF	Dedicated	Its own project. Unlimited projects, 150 per Git repository, up to 500 concurrent deployments, 1,000 variables per environment10
Files and domain	Dedicated	Its own bucket and custom domain, which is also the cleanest answer to a residency clause
Identity	Shared	One tenant with organisations. Splitting later changes every user identifier and every enterprise callback URL, and preserving password hashes can need vendor assistance23 24
Model routing, email, upstream data	Shared	Sending reputation and API quotas belong to your account rather than to a tenant. Splitting them means separate vendor contracts, not separate configuration
Control plane and pipeline	Shared	Shared by definition, and the line that keeps this one product instead of several2

The shared rows are highlighted because they are the ones nobody raises until late. Sources: 1 2 3

A cell also still runs in your cloud accounts, under your IAM, patched by your team. Worth saying early, because it is what a sophisticated reviewer asks after the architecture diagram has been agreed. The only rung that changes it is deploying into the customer's own account, and that is a different product at a different price.3

Note: a separate frontend project is a deployment and administrative boundary, not a data-isolation one. The code executes on shared infrastructure either way, and the vendor's own guidance still recommends a single deployment when every tenant runs identical code.4 That does not make splitting it wrong; it makes it a contractual choice rather than a technical one, and the schedule should say which of the two it is. Only a private-network product moves the network boundary, and that sits behind an enterprise contract.5

The tenant that is itself multi-tenant

One shape breaks the table above, and it turns up in any market with agencies in it: a customer who is not an end company but a firm serving several of them. Their cell is single-tenant to you and multi-tenant to them, so the row-level discriminator stays load-bearing inside the silo, and the cell boundary is the firm rather than the company.

That changes the tenant registry, the organisation model in the identity provider, how usage is attributed for billing, and whether one of the firm's clients can be lifted out later without a migration. None of this research covers it. The brief never asked about agency-shaped tenancy and every backend answered for one company per cell. If the first dedicated customer is a firm rather than an issuer, settle this before the registry is written, because it is a schema decision rather than a configuration one.

02 · The fleet

Provisioning the tenth instance is a morning's work. Keeping ten instances on one schema is the job

Once there's more than one, a release stops being a deploy and becomes a fleet operation. The mechanic below is the one every backend converged on, and it's the reason a single blocked cell is a fleet-wide event rather than one customer's problem.

Ten cells, one release manifest. Same commit, same image digest, same migration set.

current release upgrading expand complete blocked held back

Contract phase: waiting

The takeaway, without the animation

One release manifest per commit, pinned to an image digest and a migration set. The controller never deploys "latest" to anything.

It rolls out in waves. Canary first, then a small early-adopter group, then the rest. A wave that fails stops the ones behind it.

The expand migration completes on nine cells and blocks on the tenth. Those nine keep serving, because expand-only changes leave old code working.6

The destructive contract phase is then held back everywhere, not just on the tenth. That global hold is the forcing function; without it you have ten forks inside a year.

The discipline underneath is expand and contract, which MongoDB documents as schema versioning for gradual migration without downtime.6 It costs you four releases where a pooled app would use one. That's the real tax of a fleet, and it's the thing that lets cell ten sit on old code for a fortnight without taking anyone down.

Every cell needs its own migration ledger with a resumable cursor, so a backfill that dies at 60% resumes at 60%. At one database you can just rerun it. At ten you can't.

03 · Before cell two

Three things have to be fixed before the second cell exists, and none of them is provisioning

A Scheduled jobs

In-process schedulers register their jobs at application bootstrap and run them in that process. The framework docs offer time zones and overlap handling, but those options are process-local; there's no cross-replica leader election in the box.7

So two machines during a rolling deploy fire everything twice, and ten cells fire everything ten times. Hosted cron has the same shape, and at least one provider says outright that jobs can overlap, that the same event can be delivered more than once, and that you should hold a lock and be idempotent.8

The fix: a lease keyed on job name plus the scheduled tick, not just job name, so clock skew between machines can't slip a second run into the same window. Then deterministic jitter from a hash of the cell id, because otherwise every cell hits the same upstream vendor on the same minute against a quota that belongs to your account rather than to your tenant.

B Configuration

The env var count is the scary-looking number and the least interesting one. A lot of what gets counted is behavioural settings that are identical everywhere: log levels, thresholds, third-party endpoints, model routing. The per-tenant set is only the things that name a tenant-specific resource, and on the inventory that prompted this it came to under thirty out of roughly 380 reads.

The test worth enforcing on every new variable: is this the address of a resource, or is it a behaviour? Behaviour goes global, and a mainline commit that adds one reaches every cell with no per-cell step. Only addresses go per-tenant, and those get provisioned by the same automation that creates the resource.

The catch: shared team-level variables update every linked project, but the change only lands on new deployments.9 So a new required variable is a fleet migration in its own right: distribute it, verify every cell can resolve it, then ship the release that needs it.

C Data ownership

This is the one that gets underestimated, and one backend put it better than the others: the hard part of extracting a tenant isn't copying the collections that already carry a tenant id. It's proving ownership for everything that doesn't.

Files, job rows, cached artifacts, cross-references, and any prompt or template stored in the database. Every one of those is a place where a tenant's data can be sitting under a global-looking key.

Do this as an audit, not as part of the migration. A written manifest of which collections are tenant-owned, which are reference data, and which nobody can classify. The third list is the schedule risk.

04 · Where the panel split

Five backends agreed on the architecture and disagreed by roughly four times on what it costs, which is the most useful thing they produced

Convergence is cheap when everyone reads the same vendor documentation. The disagreements are where the reading actually paid, so they're worth setting out rather than averaging away. One of them has since been settled by a decision rather than by evidence.

Two backends quoted platform limits that had moved

Two of the five reported 60 projects per repository and 12 concurrent builds, and cited a February 2026 version of the limits page. The August 2026 page says 150 projects per repository and up to 500 concurrent deployments.10

Neither backend invented anything. They cited a real page that had since changed, and the change ran in the direction that makes per-tenant projects more workable rather than less. Which matters more now than it did when the question was asked: with a dedicated BFF per customer, those limits stop being trivia and become the operating envelope.

Resolved by re-fetching the primary source

They disagreed about where the API should run

One argued for consolidating onto the existing Kubernetes cluster so that API traffic never leaves the private network, which matters when the contract says the database isn't publicly reachable. Another pointed out that the platform-as-a-service vendor explicitly recommends one app per customer, and gives per-app secrets, regions and network segmentation for free.11 12

Both are right, and the tiebreak isn't technical. If the contract names private networking, consolidate. If it doesn't, the managed platform is one API call to create and one to destroy, which is worth a great deal at a fleet of three. Start on the managed platform and re-measure after the first cell has run a quarter.

Genuinely open · decided by the contract, not the architecture

Nobody could find the evidence anyone actually wanted

All five searched for first-hand accounts of teams who built per-customer deployments and reverted. All five came back with nothing, and said so.

That's a real hole rather than a formality. The genre doesn't exist: withdrawing isolation a customer paid for is commercially awkward to publish, and teams who do consolidate describe it as adopting a cell model rather than as a reversal. Every "what breaks first" claim on this page is therefore reasoned from architecture, not from testimony.

Unresolved · treat the failure-mode section as inference

05 · Cost

The cost is people, and the only published estimates price the cheaper architecture, so treat them as a floor rather than a forecast

Labour is the whole cost at the first cell, and infrastructure only overtakes it somewhere between three and ten

modelled labour modelled infrastructure

The figures behind this chart

Upper-bound monthly figures from one backend's published planning model. Labour is priced at US$100 per hour against an assumption of 12 hours a month at one cell rising to 70 at twenty-five.
Cells	Infrastructure	Labour	Total
1	US$500	US$1,200	US$1,700
3	US$1,500	US$2,000	US$3,500
10	US$5,000	US$4,000	US$9,000
25	US$12,500	US$7,000	US$19,500

This is a planning model the backend labelled as such, not observed market data. It assumes shared cluster capacity rather than a dedicated database replica set per customer, which is the assumption that would move it most.

Read the shape, not the numbers. At one cell the modelled labour is roughly seventy per cent of the total, and it stays ahead until somewhere between three and ten cells, where the raw infrastructure of running separate databases and separate processes finally catches up. The point isn't the crossover; it's that the first cell is almost entirely a people cost, so the second one is nowhere near half the price of the first.

Asked what a private instance has to be sold for, five backends produced a range with a four-fold spread

What each backend actually said, in its own units

Backends are anonymised by letter because the point is the spread, not which model to trust. Where a backend answered in Australian dollars or in annual contract value, we converted at A$1 to US$0.65 and divided annual figures by twelve. That arithmetic is ours, not theirs.
Backend	As stated	Basis
A	US$2,000 to US$4,000 per month	Comparison against published dedicated tiers
B	About US$4,000 per month minimum at one to three customers	Published platform prices plus a labour model
C	A$60,000 per year floor, A$100,000 to be worth doing	Fleet operations hours amortised over five cells
D	A$8,000 to A$12,000 per month plus implementation	16 to 24 engineer-weeks of productisation, 65% gross margin
E	US$25,000 to US$30,000 annual contract value uplift	Comparison against dedicated-tier premiums

Every one of these is an inference from a labour assumption, and none is a market observation. The honest reading isn't "the answer is somewhere in the middle"; it's that the number is set by how many hours a month the fleet eats, and nobody has published that figure for any control plane on the market. Four of the five said so explicitly when asked for hours per month.

Every figure above prices the cheaper architecture, because that is what the panel was asked to cost. A build with a dedicated frontend project, cache and database per customer sits above the range, so read it as a floor. What the published comparables establish is the floor's neighbourhood rather than its value. One analytics vendor lists an enterprise tier from US$20,000 a year with single-tenant hosting charged on top.13 Two of the control-plane products that would manage a fleet like this publish minimums of US$999 and US$2,000 a month before you deploy anything at all.14 15

Note: the platform seat and team fees are per team rather than per project, so the frontend cost of a second cell is close to nothing if you keep one shared project.16 That's a small thing, but it's the kind of small thing that decides whether the shared-edge recommendation holds.

06 · The control plane

Build it, because the units of deployment aren't containers and that rules out most of what's for sale

The filter is unglamorous and it decides almost everything. If your deployment units are a hosted frontend project and a managed application rather than pods, then the Kubernetes-first products can't reach half your stack. Four of the five arrived at the same answer independently: an infrastructure-as-code automation API with one stack per cell.17

It has the properties a fleet needs. Programmatic preview, update, refresh and destroy per stack; scheduled drift detection with an explicit no-changes assertion;18 and a failed stack that stays failed in isolation instead of poisoning the other nine.

The alternatives fail on specific, checkable grounds rather than on taste. Terraform's own documentation warns that CLI workspaces are the wrong tool when deployments need separate credentials and access controls, which is exactly what per-customer isolation means.19 Progressive rollout in the Kubernetes-native tooling is real and does support waves with health gating, but it only reaches the Kubernetes half of the fleet.20 And the commercial platforms aimed at this problem are mostly aimed at the rung above: deploying into the customer's own cloud, with cluster minimums to match.21

Credit where it's due: those products solve a harder problem than the one on this page, and if the requirement really is the customer's own account then building it yourself is the wrong call. The point is only that a bridge cell doesn't need them.

Note: never wire destroy to a single button. Two of the backends independently flagged deprovisioning as a critical failure mode, and one platform's own documentation warns that deleting a cluster can leave dangling resources behind.22 Make it a two-phase operation: stop routing and verify the export first, destroy the data only after the retention decision has been made by a person.

07 · What stays shared

Identity is the one to get right first, because splitting it later is the expensive mistake

Run one identity tenant and use its organisations feature, with one enterprise connection per customer. The provider documents organisation-specific login and per-organisation connections, and publishes limits well above anything a fleet of this size will reach.23

The reason to decide this on day one is that reversing it is genuinely painful. There's no direct tenant transfer; you export and import through the management API, user identifiers change, every enterprise identity provider has to update its callback URLs, and preserving password hashes can need vendor support.24 Mobile apps make it worse, since they ship a single identity domain in the bundle.

The rest of the shared surface splits along one line: keep it central when the vendor quota belongs to your account rather than to your tenant, and split it when reputation or attribution belongs to the customer.

Market data and other upstream feeds. Keep central. Ten cells independently polling the same feed is ten times the request volume for identical data, against a limit that belongs to your account.
Outbound email. Split the sending domain per customer, keep one account. Independent domain reputation is a feature, and it means one customer's bad list can't burn another's deliverability.
Model routing and keys. Central by default, with per-customer keys as an option. Letting a customer bring their own is a genuine selling point, and it moves the spend and the data-processing agreement to them.
Observability. One project per service with a cell tag, not one project per cell. Per-cell projects fragment alerting and destroy cross-fleet regression detection, which is the single most valuable signal a fleet gives you back.

08 · Compliance

In Australia almost none of this is a legal requirement, and the ones that bite are contractual

Four of the five said plainly that Australian privacy and prudential obligations don't mandate single tenancy, and the fifth agreed on the law while stressing that the enforcement date drives buyer demand. Both readings are right, and the distinction is worth holding.

Legal requirement or customary procurement demand, and whether a dedicated deployment actually changes the answer

Instrument	Status	What it actually requires	Does a silo satisfy it?
Cross-border disclosure (APP 8)	Law	Reasonable steps and accountability for overseas recipients. There is no localisation rule in the principles25	No Contracts, encryption and staying in-region already do it
Statutory privacy tort	Law, commenced 10 June 202526	Intentional or reckless conduct, and a serious invasion. Negligence isn't enough	Partly It raises the stakes of a cross-tenant leak, which is the best genuine argument for rung 1
Prudential operational risk	Law for regulated entities, in force 1 July 202627	Notification and register obligations that bind your customer, flowed down to you by contract	No But expect audit rights, incident windows and an exit plan in the contract
Continuous disclosure	Listing rule obligation on the buyer28	Market-sensitive information must not leak before announcement	The real case Pre-announcement drafts in a shared store is where a listed buyer's concern is substantive rather than reflexive
Government assurance	Applies only with government adjacency29	Formal assessment against a control manual	It's a different product This is the customer's-own-cloud conversation, with an assessment cost to match

This is a reading of published regulator and exchange material for architectural planning. It isn't legal advice, and the commencement status of reform tranches should be checked against consolidated legislation before anything goes in a contract.

Note: a residency clause is broader than the database. Backups, build artifacts, logs, telemetry, identity records, outbound mail and model traffic are all in scope, and one platform's compliance page states that it replicates platform data globally for resilience.30 Worth also checking where functions actually execute, since the default region is not necessarily the one you assume.31 A separate deployment fixes none of that; a data-flow map does.

09 · The point of no return

The thing to protect is not the first instance. It is the rule that every cell can be regenerated from one specification

One instance is a deployment. Two identical instances are a fleet. Two different instances are a fork with extra steps, and that's the state the no-fork constraint was actually about.

The clauses that create it are specific, and they're all commercial rather than technical:

Indefinite version pinning, or approval over every security patch with no maximum deferral
Per-customer code paths or patches
Hand-edited configuration or prompts on one cell
Bespoke infrastructure that can't be regenerated from the standard tenant specification
A separate mobile binary as part of the base offering

Accept those and the control plane stops being an internal deployment tool and becomes a managed-services portfolio. That's a different company, and it's worth deciding whether you want to be it before the first contract rather than after the third.

On version specifically, the published comparables are consistent. The closest analogue runs its single-tenant fleet on a scheduled maintenance window with bounded support rather than customer-chosen versions.32 33 One managed analytics product supports the current release with a limited grace period.34 What you're selling is a maintenance window. The version stays yours.

Note: the installer layer is its own risk, and it isn't hypothetical. One vendor shipped two point releases in January 2026 that broke customer upgrades through a Helm version change, and fixed it by pinning the previous major version.35 Another documents that a clustered upgrade has to be reduced to a single node, because one client takes the migration lock and running old and new nodes against a changing schema produces incorrect behaviour.36 Whatever runs your migrations is part of the product.

10 · Methods

How this page was made, and what it can't tell you

What ran

One brief with twelve enumerated subtopics, sent to five research backends in parallel and kept separate rather than merged: two local CLI agents on subscription quota, and three paid API backends. 277 cited sources between them. Reserved cost was US$20 at the top of the band; three of the five carried a charge, two were free.

What was read

All five reports end to end before any of this page was written, not the outlines and not the merged summary. That merged view is a coverage difference between reports rather than a summary of them, and a page built on it describes what the backends didn't share.

What was checked

Every citation in the two most load-bearing reports was dereferenced. 35 of 37 and 47 of 50 resolved; the failures were one bot-walled article, one government PDF that timed out, and two truncated URLs. Nothing was fabricated. Two platform limits that the reports disagreed on were re-fetched by hand and the current values used.

What a human did

Luke Rhodes set the brief, chose the framing, and reviewed the page. The research, the drafting and the build were done by Claude Code under that direction. The mechanics here are the panel's; the decision about what to build is his.

The question changed after the research ran

Worth stating plainly, because it changes how to read everything above. The panel was commissioned to answer whether to offer dedicated instances and which rung was cheapest, and it recommended against a fully dedicated stack as the default, on cost grounds. That decision has since been made the other way, on commercial grounds rather than technical ones.

The mechanics carry over unchanged, because how you run a fleet does not depend on why you chose to have one. Two things do shift: the cost figures now price the cheaper architecture and should be read as a floor, and a separate frontend project moves from unnecessary to required. The panel's recommendation is kept on the page as counter-evidence rather than quietly dropped, because a report that only contains the arguments for its conclusion is not worth much.

What this page could not establish

Hours per month to operate any control plane. Asked for explicitly. Not published anywhere by anyone, vendor or practitioner. Every labour figure on this page is therefore an assumption, and the cost section says so where it matters.
Whether pooled vendors pass enterprise security review. Procurement outcomes are confidential in every case. There's no dataset, in either direction.
First-hand accounts of teams who reverted. Searched by all five backends, found by none.
Agency-shaped tenancy. Every backend answered for one company per cell. A customer who is themselves multi-tenant, such as a firm serving several clients from one instance, was never in the brief and is not covered anywhere in the corpus.
Enterprise pricing for the platforms that matter most. Contact-sales only, which is exactly the cliff that could move the cost model by an order of magnitude.

Build notes

One scrubbed episode, in section 02. It earns its place because a reader can't otherwise hold ten independent migration timelines in their head at once and see that one blocked cell halts the destructive phase everywhere; that comparison is the claim. Every state renders directly from its identifier, so skipping ahead never leaves a claim stranded inside a half-finished animation.

3D was considered and rejected. None of the claims here depend on depth, volume or occlusion, and the fleet argument is a set of discrete states, which small multiples carry better than a scene would.

The page is one file with no webfonts and no external assets beyond the animation library. It's set in whatever grotesque and monospace your system provides, which is a deliberate trade of typographic control for not depending on a font CDN that has to still exist in five years.

Sources

Every figure on this page opens

Numbered by first appearance. All accessed 10 August 2026.

Silo, pool and bridge modelsAWS Well-Architected SaaS Lens · defines the three tenancy models and the deliberate mix · vendor architecture guidance
The bridge modelAWS, SaaS Tenant Isolation Strategies · establishes that isolation is a per-resource decision and pooled-with-siloed-data is a normal pattern · vendor whitepaper
Logical separation case studyAWS · a case where logical separation plus dedicated tenancy met the intent of physical isolation for many workloads · vendor whitepaper
Multi-project platforms conceptsVercel, updated 26 June 2026 · scopes per-tenant projects to platforms running tenant code, and recommends multi-tenant to deploy once and update all tenants · vendor documentation
Secure Compute is now self-serveVercel changelog, 7 January 2026 · private networks, regional placement and dedicated egress addresses, on the enterprise plan · vendor release note
Data versioning patternMongoDB manual v8.2 · schema versioning for gradual migration without downtime, the basis of expand and contract · vendor documentation
Task schedulingNestJS documentation · schedules register at application bootstrap and run in that process; the options provided are process-local · framework documentation
Managing cron jobsVercel, updated 28 January 2026 · states that jobs can overlap and events can be delivered more than once, and recommends locking plus idempotency · vendor documentation
Shared environment variablesVercel · team-level variables link to many projects; project values override them, and changes only affect new deployments · vendor documentation
LimitsVercel, updated 3 August 2026 · unlimited projects, 150 projects per Git repository, up to 500 concurrent deployments, 100 cron jobs per project, 1,000 environment variables per environment · vendor documentation
Why one app per userFly.io · the platform's own recommendation of app-per-customer, for per-app secrets, logging, scaling and network segmentation · vendor guidance
Machines API, apps resourceFly.io · programmatic app creation and deletion, region selection and named private networks · vendor API documentation
PricingMetabase · enterprise tier from US$20,000 a year, with single-tenant hosting charged additionally · vendor pricing
PricingOmnistrate · US$999 a month minimum for a managed control plane, before customer workload infrastructure · vendor pricing
PricingReplicated · Builders at US$2,000 a month plus per-licence fees · vendor pricing
PricingVercel · Pro at US$20 a month per team including one deploying seat, charged per team rather than per project · vendor pricing
Automation APIPulumi · programmatic stack lifecycle intended for wrapping infrastructure deployment inside a higher-level application · vendor documentation
Drift detectionPulumi · scheduled drift detection and remediation, including an explicit expect-no-changes assertion · vendor documentation
WorkspacesHashiCorp · warns that CLI workspaces are inappropriate where deployments require separate credentials and access controls · vendor documentation
ApplicationSet specificationArgo CD · rolling sync with label-selected waves and a maximum update count, stalling on an unhealthy application · open-source documentation
Bring your own cloud requirementsNorthflank · minimum 12 vCPU and 24 GB per cluster, and no full deinstallation process for the key-management variant · vendor documentation
PricingPorter · per-vCPU and per-GB platform pricing excluding cloud cost; its documentation also warns that cluster deletion can leave dangling resources · vendor pricing
Organizations overviewAuth0 · organisation-specific login and per-organisation enabled connections, with published entity limits · vendor documentation
How to clone a tenantAuth0 support, 4 November 2025 · no direct tenant transfer; export and import through the management API, with password hashes possibly needing vendor assistance · vendor support documentation
APP 8, cross-border disclosureOffice of the Australian Information Commissioner · reasonable steps and accountability for overseas recipients; no data localisation rule · regulator guidance
Statutory tort for serious invasions of privacyOffice of the Australian Information Commissioner · commenced 10 June 2025; requires intentional or reckless conduct and a serious invasion · regulator guidance
Prudential Standard CPS 230Australian Prudential Regulation Authority · operational risk management and material service provider obligations, in force 1 July 2026 · prudential standard
Guidance Note 8, continuous disclosureASX · treats market-sensitive information and cyber incidents as disclosure questions rather than prescribing infrastructure · exchange guidance
Cloud assessment and authorisationAustralian Cyber Security Centre · assessment of provider controls against the Information Security Manual, relevant to government procurement · government guidance
Security and complianceVercel, updated 21 January 2026 · states that platform data is globally replicated for resilience, with regional failover · vendor documentation
Configuring function regionsVercel · function execution region selection and the platform default · vendor documentation
Internal releases for single-tenant instancesGitLab handbook · the single-tenant fleet runs behind mainline with security releases folded in, on a maintenance window rather than customer-chosen versions · vendor engineering handbook
Maintenance policyGitLab · the release and patch cadence the dedicated fleet is scheduled against · vendor policy documentation
Support services policyClickHouse, 8 June 2026 · managed products support the current release, with a limited grace period for designated customers · vendor support policy
Embedded Cluster release notesReplicated · versions 2.13.1 and 2.13.2 broke upgrades through a Helm server-side apply change; 2.13.3 pinned the previous major version to restore compatibility · vendor release notes
UpgradingMetabase · clustered upgrades must be reduced to one node because a single client takes the migration lock, and running old and new nodes against a changing schema can produce incorrect behaviour · vendor documentation

The dedicated stack is a fortnight.
The fleet is forever.

In short

Build order