What self-hosting actually costs
This is the strongest objection to everything else on this site, so it gets its own page rather than a footnote. Managed services are expensive for a reason, and the reason is that running a database well is a job.
The pitch for self-hosting is usually made with two numbers side by side: your DynamoDB invoice, and the monthly cost of the instances you would run instead. The second number is smaller, often dramatically, and the slide moves on.
That comparison is wrong in a specific and predictable way. It compares a service to a server, when what you are really buying from a managed provider is a service plus a team plus a set of procedures that have been tested on someone else's incidents. Leave the people out of the sum and self-hosting always wins on paper and frequently loses in practice.
So here is the bill, written out. If it puts you off, that is the correct outcome and it cost you eight minutes instead of eight months.
The line items
Some of these are obvious and priced in every plan. Others show up in month seven.
| Line item | What it actually involves | Usually forgotten? |
|---|---|---|
| Hardware or instances | Nodes, disks, and the replication factor multiplying both. Three replicas means three times the storage, always. | No |
| Headroom | You cannot run a database at 90% of capacity. The gap between what you use and what you provision is a permanent cost. | Often |
| Cross-zone traffic | Replication crosses availability zones by design, and in most clouds that is metered. | Very often |
| Backups | Storing them, in a different failure domain, with a retention policy someone has agreed to. | No |
| Restore drills | A backup you have never restored is a hypothesis. Testing it is recurring, scheduled work. | Almost always |
| Upgrades | Reading changelogs, rehearsing in staging, rolling through production, and the rollback plan for when it goes wrong. | Often |
| Monitoring | Metrics collection, dashboards, alert thresholds that are neither noisy nor silent, and the tuning that gets them there. | Partly |
| On-call | A rotation deep enough to be sustainable, with people who understand quorums at 3am. | Almost always |
| Security | Patching, network policy, key management, and whatever your auditors ask for that the managed service used to answer. | Often |
| Expertise | Someone who has actually operated a distributed database, or the time for someone to become that person. | Always |
The last row is the one that decides the outcome, and it is the hardest to put a number on.
Who pays it
The failure mode is not that these costs are unknown. It is that they are assigned to "the platform team, somehow" — which is to say, to no one, until an incident assigns them at 3am to whoever answers.
Two questions are worth more than a spreadsheet:
- Name the person who is paged when the database is down. Not the team. The person. Then name their backup, and the backup's backup, because a rotation shallower than about five people is one resignation away from being one person.
- Name the date of your next restore drill. If there isn't one on a calendar, you do not have backups. You have files.
If both answers exist and are comfortable, you probably already run stateful infrastructure and the marginal cost of one more system is genuinely modest. If either answer is a shrug, the honest read is that the managed service is doing more for you than the invoice suggests.
The comparison that is actually fair
Put like for like on both sides:
Managed
Invoice, plus the engineering time you still spend on capacity modelling and cost control, plus the coupling you accrue, plus the switching cost you are compounding.
Self-hosted
Infrastructure, plus headroom, plus cross-zone traffic, plus backup storage, plus the fraction of a team that operates it, plus the recruitment cost of that skill set, plus the incidents you will handle yourself.
Done properly, the sum is much closer than either camp likes to admit, and it flips on the details of your situation rather than on principle.
When self-hosting wins
- Steady, predictable, high volume. Managed pricing is a bet on variance. If your load is flat and large, you are paying for optionality you never use.
- You already run stateful infrastructure. The second database on an existing platform team costs a fraction of the first.
- The requirement is not commercial. A residency clause, an air-gapped site, a ship at sea. When the managed option cannot satisfy the requirement at any price, cost comparison is beside the point.
- Data gravity elsewhere. If the compute that reads this data already lives in your datacentre, keeping the data next to it removes egress and latency at once.
When it loses
- Spiky or unpredictable load. You will provision for the peak and pay for it at the trough, which is precisely what you were paying the managed service to do for you.
- A small team. Below a certain size, every hour on database operations is an hour not spent on the product, and that trade is almost never worth it.
- No on-call culture. Adding a stateful system to a team without a rotation does not add a system. It adds an outage with a delay fuse.
- Compliance you currently inherit. Some certifications are easier to hold because a provider holds them for you. Taking the system in-house moves that work to you.
The AnimusDB-specific bill, today
Everything above is the general case. The specific case is worse, and pretending otherwise would undo the point of writing this at all.
Today AnimusDB is pre-alpha. TLS exists on every port but is off by default, and client authentication is opt-in SigV4 on the DynamoDB port. A whole-cluster stop, upgrade and restart keeps the data, but rolling upgrades and mixed-version clusters are not supported yet, so every upgrade is downtime. Nothing has had a multi-day soak or real-cluster chaos testing either. What is still missing before AnimusDB leaves pre-alpha is written down as a checklist in the repository (docs/production-readiness.md). Until that list is done, the correct amount of production data to put in AnimusDB is none.
So the honest version of the bill is in two parts.
What it costs to evaluate it now
An afternoon. Three nodes in one process, your integration suite pointed at a different endpoint, and an answer to the question of whether your access patterns really are portable. That is a genuinely useful thing to know regardless of what you do next.
What it will cost to run it later
Every line in the table above. When the gaps close, the operational bill for AnimusDB will be an ordinary distributed-database bill, and nothing on this site should suggest that self-hosting has been made cheap. It has been made possible without a rewrite. Those are different claims.
A worksheet, not a verdict
If you want to price this properly, these are the numbers to go and get. Every one of them is specific to you, which is why nobody else's comparison table is worth much.
- Your current invoice, split into storage, reads, writes, streams and cross-region.
- Node count and instance size you would need, times your replication factor, plus your headroom target.
- Cross-zone traffic at your write volume, times replication factor, at your provider's rate.
- Backup storage at your retention policy, in a separate failure domain.
- Fraction of an engineer, per month, for operations — and be honest, it is not 0.1.
- The recruitment or training cost of the expertise, amortised over how long you expect that person to stay.
- The cost of one bad day: your worst plausible outage, priced in revenue and in customer trust, times the probability you assign to handling it worse than the provider would.
Add up the right-hand column. If it comes out clearly in favour of staying managed, stay managed — and take the exercise as having produced the number from the lock-in argument that nobody in your company had.
Keep reading
Why lock-in compounds
The argument this cost is weighed against, including an explicit concession that this is not a case against AWS.
Day-two operations
Exactly which operational tools exist today and which don't, without the marketing gloss.