An interface-compatible hosted tier speaks the client protocol you already use — what does that promise about its ceilings, and what must you diff?

## What the compatibility promise covers An **interface-compatible tier** is a hosted service that speaks a client protocol you already use while being a different implementation underneath. The promise being made is narrow and specific: an existing client library can connect, and the calls it makes are understood and answered. That is genuinely valuable — client code is unchanged, the people who operate it already know the call vocabulary, and existing tooling attaches. But it is a statement about an interface, and an interface describes what may be asked, not what will be permitted. It helps to separate three readings people make of the same sentence: 1. **"My client connects."** This is what is promised, and it is usually true. 2. **"My operational knowledge transfers."** Partly true, and unevenly — the vocabulary transfers, the failure modes often do not. 3. **"My ceilings carry over."** Not promised, not implied, and the most expensive of the three to assume. ## Why ceilings are where the difference surfaces first A client protocol describes messages on a connection. It says nothing about how many objects a cluster admits, how many connections it will hold, how large one message may be, or how long history is kept — and those are precisely the properties a re-implementation exists to change. A service is usually rebuilt in order to be cheaper, more elastic or simpler to operate, and each of those goals is achieved by making a different structural choice. Different structure, different ceilings. The pattern to expect, stated as variation rather than as fact about anyone: - Implementations backed by **shared bulk storage** rather than per-node volumes often admit far more objects and far longer history, while being tighter on per-object throughput or on how quickly a single reader can catch up. - Implementations whose metadata lives in **one coordination service** frequently cap object counts per cluster well below what a design that spreads metadata allows. - **Consumption-priced** offerings, where capacity is not reserved for you, tend to cap concurrent connections and outstanding work more firmly, because those are the dimensions that let one tenant consume another's headroom. - Some re-implementations are **more generous** in one class and stricter in another, which is why a single headline comparison is meaningless and a row-by-row one is not. The practical consequence is that the first thing you meet on the new tier is not a protocol incompatibility — the protocol works, that was the point — but a refused create call, a rejected connection, or a message the broker will not accept. Those arrive after migration, under real traffic, in the class you did not check. ## The diff to run before committing 1. **Enumerate your demand** in each ceiling class on the incumbent: object counts, connections and sessions, single-message size, outstanding work per subscription, kept history. Use what you actually run, plus the peak, plus two years of growth. 2. **Obtain the candidate's ceiling sheet** and align it row to row. Record the **scope** of each ceiling — per cluster, per namespace, per stream, per paying scope — because a ceiling that looks lower may be counted per namespace and therefore be effectively larger. 3. **Mark each row raisable or not.** Only the rows nothing lifts constrain the decision; the rest is capacity planning with a lead time. 4. **Probe what is not published.** Ceiling sheets are incomplete by default, and the absent rows are the interesting ones. A trial that creates objects until creation is refused, or sends an increasing message until one is rejected, produces the number the sheet omitted. 5. **Decide on the strictest row, not the average.** A tier that is more generous in four classes and stricter in one is ruled out by the one, if the one is a class your design depends on. ## What this does and does not settle This analysis answers a single question: does the candidate's set of unraisable ceilings fit the design you actually run? It does not settle whether the operational behaviour matches under failure, whether the performance profile holds, or what the migration costs — those are separate investigations with separate evidence. What it does do is dispose of the most common failure in this decision, which is a proof of concept that connects successfully, passes, and proves the one thing nobody doubted. At the scale where this question is asked — an estate, not a service — the discipline generalises. The compatibility promise is read strictly, written down in the terms it was actually made, and every assumption that goes beyond it is listed as an assumption and tested. A promise about an interface is a promise about an interface.