Why lock-in compounds

Every procurement process your company runs assumes one thing: that you could walk. The discount you get, the SLA you extract, the roadmap commitment you extract with it — all of it is priced off the credibility of your alternative. Strip the alternative out and the negotiation is not a hard negotiation. It is a briefing.

Most infrastructure dependencies keep the alternative alive without anyone maintaining it. Swap one object store for another and the work is measured in weeks. Change CI providers and you rewrite some YAML. These are dependencies you could leave, which is exactly why you rarely need to.

Databases are not like that, and DynamoDB is a particularly clean example of why.

What you actually bought

You did not buy a key/value store. Those are commodities and always have been. What you bought was a way of thinking about your data that turned out to be extremely good: partition keys, sort keys, single-table designs, sparse and overloaded indexes, conditional writes standing in for locks, streams standing in for change capture.

That model is genuinely excellent. It is also the thing that binds you, because it is not confined to a data-access layer you could swap. It is diffused through your application — in the shape of your keys, the assumptions your services make about what a read costs, the retry logic built around throttling responses, the Lambda triggers hanging off your streams, the way your team reasons about a new feature before anyone opens an editor.

You cannot refactor that out in a quarter, because it is not in one place. It is in everything.

The bill nobody decides to run up

Here is the part that deserves the word compounds.

On the day you adopted DynamoDB, your switching cost was close to zero. You had one table and a prototype. Nobody made a subsequent decision to increase it. But every feature shipped since then added access patterns. Every access pattern added coupling. Every new engineer learned the model as the way things are done here, and reproduced it. Every incident postmortem hardened some workaround that assumes the specific behaviour of the specific service.

Nothing on that list was a bad call. Each was locally correct. But the aggregate is a switching cost that grows monotonically, that nobody owns, that appears on no plan, and that is never reviewed — because reviewing it would require someone to price a migration nobody is proposing.

By the time a reason to move arrives — an acquisition, a regulator, a price change, a region that doesn't exist, a customer contract with a data-residency clause — the cost of moving has been compounding for six years. It gets refused on those grounds. And the refusal is correct. That is what makes it a trap rather than a mistake.

The renegotiation you can't have

Consider what you are actually accepting when the exit is closed.

One vendor sets the price, and revises it on their schedule. One vendor decides which regions exist, and therefore which jurisdictions you can promise a customer. One vendor defines your recovery-time objective, because when it is down you are down and the honest content of your incident update is that you are waiting. One vendor decides what happens to a service when it stops being strategically interesting to them.

None of these are hypothetical grievances against a specific provider. They are the structural position of any buyer without an alternative, and you would never knowingly sign it. You did not knowingly sign it here. It accumulated.

What an exit is worth if you never take it

The reflex objection to any of this is: we are not going to migrate our database, so who cares.

Probably you are not, and probably you shouldn't. But an option has value distinct from exercising it, and the value shows up in places that never look like migrations:

• In the contract. A credible alternative is the only thing that makes a renewal a conversation.
• In sales. "Yes, we can run that dataset inside your jurisdiction" is a sentence that closes enterprise deals. Today it is a sentence you can only say if a region happens to exist and a compliance officer accepts the answer.
• In architecture. Teams that know the data layer is portable design differently — and, as it happens, better. Coupling you can see is coupling you can bound.
• In risk registers. "Single-supplier dependency, no mitigation" is an entry your board can read. Auditors increasingly ask for the exit plan by name.

An unexercised exit is cheap insurance against a scenario that is unlikely each year and near-certain across a decade.

Where the cost actually sits

If you did decide to price a move today, the estimate would be dominated by one line: rewriting every access pattern against a different data model, and re-earning the operational knowledge that goes with it. Cassandra, Postgres and MongoDB are all fine databases, and all of them ask for that rewrite.

That is the line AnimusDB is aimed at, and it is the only line it removes. The API stays. The SDKs stay. The keys, the queries, the conditional writes, the pagination and the mental model all stay. What changes is who runs the cluster and where it sits.

This is not an argument against AWS

It would be easy to read all of the above as a case against a company. It isn't, and it is worth being explicit, because an argument that needs a villain is usually a weak argument.

DynamoDB is an outstanding piece of engineering. Its data model has aged better than almost anything else from its era, its operational record is one very few teams could match, and the decision to build on it was, for most people who made it, correct. AWS has earned its position by being reliably better than the alternatives for a long time.

Most teams should stay on managed services, including this one. If you are on AWS, happy, and expect to be in five years, self-hosting a database is a downgrade in every dimension you will feel day to day. Operational burden is real and a managed service absorbing it is worth a great deal of money.

The argument here is narrower, and it survives all of that being true: a dependency you cannot leave is priced differently from one you can, and the difference grows. Wanting an exit is not a complaint about the current supplier. It is the ordinary posture of a buyer who intends to still be a buyer in ten years.

What to do about it, concretely

Nothing on this list requires adopting anything.

1. Price the move. Not to do it — to know the number. If nobody in the company can produce an estimate, that is itself the finding.
2. Find the coupling that isn't the API. Streams consumers, IAM policy as authorisation logic, throttling-aware retry code, anything that assumes a specific region list. This is where migrations actually die.
3. Write the exit clause into the risk register, with an owner and a review date, so the number gets recalculated while it is still small enough to act on.
4. Keep the option warm. An alternative you have never run is not an alternative. An afternoon pointing your integration suite at something else is the cheapest hedge available.

AnimusDB is pre-alpha and you should not put production data in it. But the fourth item on that list costs an afternoon, and the first three cost nothing at all.

Keep reading