Infrastructure Comparisons
Side-by-side trade-offs where neither column wins. The workload, the team and the operational budget decide — and each comparison ends with the verdict that follows from that, not from a preference.
VM vs Container vs ServerlessManaged vs self-hosted databaseObject vs block vs file storageRolling vs blue/green vs canaryActive-passive vs active-activeDeclarative vs imperative infrastructure
Managed vs self-hosted database
Not a question of capability but of where the operational boundary sits, and whether operating a database is where your team should be spending its attention.
| Dimension | Managed | Self-hosted |
|---|---|---|
| Backups and patching | Provider, on a schedule you configure | Yours, including verifying they work |
| Replication and failover | Provider, usually one switch | Yours to build, test and trust |
| Version and extension control | Constrained to what the provider supports | Complete |
| Tuning depth | Limited to exposed parameters | Anything, including the filesystem |
| Schema, queries, indexes | Yours | Yours |
| Access control and capacity | Yours | Yours |
| Cost | Higher per unit, lower in people | Lower per unit, higher in people and risk |
| On-call at 3 a.m. | Escalate to the provider | You |
Use Managed when
- The team's edge is the product, not database operations.
- You need failover and backups to work without a project to build them.
- Compliance is satisfied by the provider's controls.
Use Self-hosted when
- You need an extension, version or configuration the provider does not offer.
- You have genuine database operations expertise on staff.
- Scale or regulation makes the managed offering unworkable.
Verdict
Managed by default, and self-hosted when you can name the specific capability the managed offering lacks. Either way, the schema, the queries, the indexes and the bill are yours.
Lessons behind this comparison