Main idea

When the customer pays for its own Azure SQL, the instinctive reasoning is that its subscription should cost less: a cost line has just left the vendor's scope.

It has left, and another one has opened. Supporting databases installed at customer sites forces you to handle different versions, different network constraints, replication mechanisms, backups, snapshots, restores, permissions, monitoring, specific configurations — and above all many more scenarios to reason about when something stops working.

Infrastructure cost goes down, cost of service goes up. They are not the same lines, and nothing guarantees the second is smaller than the first.

Why it matters

The instinctive reasoning leads you to grant a discount at the very moment the real cost is rising. The error is structural: you compare what is easy to price — the price of a resource — with what isn't — the variety you have to support.

It also gives a rule for the commitments that come with it. Guaranteeing the restore of a database hosted on the customer's side requires technology, tests, monitoring, recovery procedures: it is an additional responsibility, and therefore a line to be priced. If the customer prefers to keep it, retention, backup quality and the consequences of an unusable backup must be explicitly assigned to them.

Nuances and limits

The increase depends on the variety actually accepted. A single supported version, a single configuration, and the extra cost stays modest.

And part of the cost is learning: the first deployments cost more than the ones that follow, which distorts any extrapolation made too early.

Open questions

• How do you price a cost of service in advance, when it depends on the variety you will have accepted?