The Self-Hosting Decision: When SaaS Costs More Than Your Own Infrastructure
The comparison appears straightforward: a managed database service charges a substantial monthly subscription; a VPS costs a fraction of that. If the workload fits on the VPS, the choice seems obvious. But in reality, the subscription fee comparison is the least meaningful part of the self-hosting decision. The factors that determine whether self-hosting actually costs less – over a two-to-three year horizon, which is the relevant timeframe for infrastructure decisions – are almost entirely absent from the initial calculation.
What the subscription fee represents
A managed database subscription buys a service, not hardware. The subscription covers the infrastructure cost, but it also covers the engineering time of the people who built the service, maintain it, apply security patches, respond to incidents, and ensure it meets the compliance certifications that enterprise customers require. It covers the operational knowledge those engineers have accumulated about running that software at scale. It covers the on-call rotation that wakes someone up at 3am when a disk fills unexpectedly.
The VPS subscription does not include any of that. The VPS provides compute. Everything else is provided by whoever manages it. This is not an argument against VPS hosting – it is a clarification of what the cost comparison actually represents. When comparing a $50/month VPS to a $300/month managed service, the question is not whether the hardware is worth $250 more per month. The question is whether the operational responsibilities transferred to you are worth $250 less per month to carry. For some teams and some workloads, they are. For others, they are not.
The true cost: operational time
Experienced infrastructure engineers tend to underestimate how much time self-hosted services consume in steady-state. The initial setup is visible and bounded: it takes some hours to configure the service, establish monitoring, configure backups, set up TLS termination. What is less visible is the ongoing maintenance surface that accumulates quietly.
A database installation requires periodic version upgrades. Minor upgrades are typically straightforward. Major version upgrades require testing on a staging environment, a maintenance window, and a rollback plan if something goes wrong in production. Security patches – particularly for software like PostgreSQL, Nginx, or Redis, which have long histories of CVE publications – require rapid response when a high-severity vulnerability is announced. Monitoring requires recalibration: alert thresholds that work correctly at one traffic level require adjustment at another. Backup verification – actually restoring from backup to confirm the process produces a working database – requires dedicated time that almost never gets scheduled unless it is formally planned.
A conservative estimate for a single production database running a non-trivial application: four to six hours per month in steady-state operational overhead, plus unscheduled incident time. Over a year, this is between fifty and seventy-five hours of engineering time. At any credible rate for competent infrastructure work, this number exceeds the annual cost difference between self-hosted and managed for a single instance. The VPS is cheaper. The total cost of running it is not.
The security burden
Managed services employ dedicated security teams. Self-hosted means you are the security team. This asymmetry is most visible when a vulnerability is announced for a component in your stack. A managed service patches automatically or notifies you that it has been patched and the action required on your side is minimal. Self-hosted means you receive the CVE disclosure, assess the severity against your specific configuration, plan a maintenance window that minimises downtime, apply the patch, verify that the fix works correctly and has not broken anything, and update your monitoring to detect the class of issue the CVE addressed.
For a team that does this professionally and treats it as a primary responsibility, the overhead per incident is manageable. For a small team where infrastructure management is one responsibility among several, the overhead is significant – and the risk of delayed patching is real. A high-severity PostgreSQL vulnerability announced on a Tuesday afternoon competes with product work, customer commitments, and the other items already on the priority list. Managed services remove this competition entirely. This is not a trivial benefit.
When self-hosting genuinely wins
The economics shift materially in three situations, and only in these three.
Multiple instances on shared infrastructure. The operational overhead of self-hosting does not scale linearly with instance count. A team running five PostgreSQL instances on one server does not spend five times as much operational time as a team running one. The monitoring setup, the upgrade procedures, the backup infrastructure, the TLS configuration – much of it is shared. The cost per instance for five instances on a single server drops significantly compared to a single isolated instance. This is the scenario where self-hosting clearly wins on total cost, and it is why many consultancies and agencies running multiple client projects operate their own infrastructure. The fixed cost of building operational competence is spread across enough instances to justify it.
Data sovereignty requirements. Certain industries and certain clients require data to remain within specific geographic boundaries, within infrastructure the client controls, or under contractual terms that public cloud providers do not offer. When data sovereignty is a genuine requirement rather than a preference, self-hosting is often the only viable path. The managed service either cannot meet the geographic requirement, the contractual terms are insufficient for the regulatory context, or the compliance attestation it provides does not cover the specific obligation. In these cases the self-hosting decision is not primarily economic – it is a constraint imposed from outside.
Deep customisation needs. Managed services are opinionated. PostgreSQL on a major cloud provider runs a specific version range, with a specific set of available extensions, with configuration parameters that are exposed selectively. If the application requires custom extensions, non-standard PostgreSQL builds, or configuration options that are not available via the managed service API, self-hosting is a technical requirement rather than a cost choice. This situation is less common than teams expect when they first evaluate it, because most applications work within the constraints managed services impose. When it is genuinely required, however, it is conclusive.
When self-hosting loses
Team turnover makes self-hosted infrastructure fragile in a way that managed services are not. Self-hosted infrastructure accumulates institutional knowledge over time: how it was set up, what non-obvious configuration decisions were made and why, which monitoring rules have been tuned and which are still at their defaults, what the actual backup restoration procedure involves in practice rather than in theory. That knowledge lives in the people who built and operate it. When the person who knows the system leaves, and the documentation is incomplete – which is the normal condition – the next person inherits an opaque system without the context to operate it safely. Managed services transfer this knowledge problem to the provider. The knowledge required to operate a managed service is largely transferable between engineers because it is documented by the provider: you need to understand the service’s API and how your application uses it, not the configuration decisions made three years ago on the underlying server.
Compliance requirements that mandate managed infrastructure represent a related category. SOC 2, HIPAA, PCI DSS, and similar frameworks involve audits of the infrastructure processing regulated data. A managed service from a major cloud provider typically provides pre-built compliance attestations for these frameworks – the audit evidence is collected automatically and the provider’s compliance programme covers your deployment. Self-hosted infrastructure requires developing and maintaining that evidence independently, which is a significant compliance engineering effort. For organisations that need to demonstrate compliance to customers or auditors, self-hosting can multiply the compliance programme cost to a point where the managed service subscription looks inexpensive.
Rapid or unpredictable growth is a third category where self-hosting loses. Self-hosted infrastructure requires capacity planning: you provision for a projected peak load, and when load exceeds that projection, the system degrades or fails until capacity is added. Managed services handle capacity automatically or with minimal configuration. When load patterns are uncertain – a product launch, a media mention, a viral moment, a seasonal spike that is larger than historical data suggests – the managed service absorbs the variance. The self-hosted server does not. The cost of an outage at a moment of high demand typically exceeds the difference in infrastructure spend for a significant period.
A practical decision framework
The single most predictive factor for whether self-hosting makes economic sense is instance count. One instance: the total cost of self-hosting including operational time almost never comes out below managed, and the hidden costs of security incidents and team turnover add meaningful downside risk. Three to five instances on shared infrastructure: the economics become genuinely competitive and self-hosting is worth a careful total-cost analysis. Beyond that, the fixed overhead of building operational competence is spread across enough instances that the case for self-hosting is often compelling.
After instance count, assess team stability honestly. If the team that will operate the infrastructure is technically capable and turnover is low, the institutional knowledge risk is manageable – document aggressively and the cost is contained. If there is meaningful probability that the infrastructure will need to be operated by people who were not involved in building it within the decision’s relevant horizon, the hidden costs rise substantially.
Identify compliance and data requirements before making the infrastructure decision, not after. The cost of discovering mid-project that the self-hosted setup does not meet a compliance requirement – and migrating to managed infrastructure under deadline pressure – is considerably higher than the cost of assessing the requirement at the start. Compliance requirements that favour managed services are not always obvious before you engage with the specific regulatory context.
The self-hosting decision is not a statement about technical capability or independence from vendors. It is an economic and operational choice, and the correct answer depends on the specific combination of instance economics, team stability, and technical requirements. The mistake is treating the subscription fee as the whole story. It is rarely more than a third of it.