A per-core database licence makes horizontal scaling more expensive than vertical. How does that change your design, and would you challenge it?

What is being tested

Whether you treat a commercial constraint as a genuine architectural input, and whether you know when to push back on it.

How it changes the design

The licence inverts the usual scaling instinct, and the design should follow it honestly:

• Scale vertically first, further than you otherwise would. A larger instance with the same core count is free; more instances are not.
• Reduce database load architecturally rather than adding capacity: aggressive caching, read offload to a cheaper or open-source replica where the licence permits, moving analytical workloads to a warehouse entirely.
• Move workloads off the licensed engine where they do not need it — sessions, queues, search, time-series and caching all have unlicensed alternatives, and each one removed reduces the core count the licence must cover.
• Watch non-production. Development and test environments licensed at production rates can double the cost and quietly discourage realistic testing, which is a worse outcome than the money.
• Check how the licence counts cores in virtualised and containerised environments. Some count physical cores on the host regardless of allocation, which makes containers surprisingly expensive and is a common and unpleasant discovery.
• Check whether disaster recovery capacity is licensed even when idle, which changes the economics of warm standby versus backup-and-restore.

Whether to challenge it

Yes, and in three ways — but understand the leverage first.

1. Negotiate. Licensing is more flexible than the price list suggests, particularly at renewal or when a competitor is credibly in play. The provider knows your exit cost as well as you do, which is precisely why the negotiation must start before you are cornered.

2. Price the migration. If the licence constrains the architecture materially, calculate the cost of moving to an open-source or differently-licensed engine and compare over three to five years, including the engineering time and the risk. Sometimes the migration is obviously worth it and nobody had done the arithmetic.

3. Escalate as a business decision. This is a commercial constraint producing a technical limitation. The organisation should decide it with the numbers visible, rather than engineers quietly building around it and the cost never being attributed to the licence.

The strategic point

What is the exit cost? A licence whose price rises 40% at renewal is only a problem if you cannot leave. Preferring open standards and open protocols — even with a commercial implementation — preserves the option, and that option is what constrains the renewal conversation.

This is also the argument for preferring managed versions of open interfaces over proprietary ones at similar cost: the migration path is a restore rather than a rewrite.

What a strong answer adds

Naming this as an instance of a general pattern: commercial models shape architecture more than teams expect, and the licensing model should be checked before a design is committed rather than discovered when it proves uneconomic at scale. Per-core, per-instance, per-environment and per-request pricing each push the design in a different direction.