A SQL Managed Instance is a Platform-as-a-Service relational database — the team gets a managed Postgres, MySQL, or SQL Server without operating the server, the OS, the backups, or the replication. The right answer is a managed instance for a team that does not have a dedicated DBA, a team that wants to focus on the application instead of the database, a team that needs the SLA that a managed provider offers. The wrong answer is self-hosted for a team that has the operator time and wants full control, or a serverless database (Neon, PlanetScale) for a team that does not need the managed features.
Table of contents
- The PaaS database — what the team gets
- The cost — pay for the instance, not the operator
- The migration story — moving to a managed instance
- The backups — automatic, point-in-time, retention
- The high availability — replicas, failover, multi-AZ
- The monitoring — metrics, slow query log, query insights
- When to use a managed instance (and when not to)
- How this fits the rest of the stack
- FAQ
The PaaS database — what the team gets
A SQL Managed Instance is a managed database. The team gets a connection string, the team connects from the app, the team does not see the server. The provider handles the OS, the patching, the backups, the replication, the failover, the monitoring. The right answer is a managed instance for a team that wants to focus on the application, not the database.
The gotcha: the team does not have shell access to the server, the team does not have root access to the database. The team that needs to run a specific Postgres extension that the provider does not support is better off with a self-hosted instance.
The cost — pay for the instance, not the operator
The cost of a managed instance is the instance size (CPU + memory + storage) plus the egress. The right answer is to model the cost at the team’s actual usage, not the vendor’s headline price. The right answer for a small team is the smallest instance, the right answer for a high-traffic team is a larger instance or a read replica.
The gotcha: the managed instance has a higher per-hour cost than a self-hosted instance, but the team is not paying for the operator time. The right answer is the managed instance for a team that does not have a DBA, the right answer is self-hosted for a team that has the operator time and a clear cost calculation that favors self-host.
The migration story — moving to a managed instance
The standard migration path is pg_dump (Postgres) or mysqldump (MySQL) for a logical backup, restore on the managed instance, switch the app’s connection string. The right answer is the dump-and-restore for a small database (< 10GB), the right answer is a logical replication or a managed migration tool (AWS DMS, Google Database Migration Service) for a large database.
The gotcha: the migration has downtime. The right answer is a blue-green migration (the team has both instances running, the app switches over) or a logical replication (the team replicates from the old to the new, the app switches when the new is caught up).
The backups — automatic, point-in-time, retention
Managed instances have automatic backups (daily snapshots) and point-in-time recovery (the team can restore to any second in the retention window, typically 7-35 days). The right answer is to enable the automatic backups and to test the restore (a backup that the team has never restored is not a backup).
The gotcha: the team’s compliance requirement may need a longer retention (90 days, 1 year). The right answer is to enable the long-term retention option, the wrong answer is to assume the default retention is enough.
The high availability — replicas, failover, multi-AZ
Managed instances have high availability built in. The provider runs the database across multiple availability zones, the failover is automatic, the team’s app reconnects after a few seconds. The right answer is to enable the multi-AZ option for a production database, the wrong answer is to assume the single-AZ option is enough — the team’s database is down for the duration of the AZ failure.
The monitoring — metrics, slow query log, query insights
Managed instances have built-in monitoring (CPU, memory, disk, IOPS, connections) and query insights (the slow query log, the most expensive queries, the missing indexes). The right answer is to set up the alerts (the team is paged when CPU > 80% for 5 minutes), the right answer for a slow query is to use the query insights to find the query and add the missing index.
When to use a managed instance (and when not to)
Use a managed instance when:
- The team does not have a dedicated DBA.
- The team wants to focus on the application, not the database.
- The team needs the SLA that a managed provider offers.
- The team’s compliance requirement is met by the provider’s certifications.
Don’t use a managed instance when:
- The team has a dedicated DBA and wants full control.
- The team needs a specific Postgres extension that the provider does not support.
- The team’s cost calculation clearly favors self-host (rare, but possible at scale).
- The team needs root access to the database server (rare, but possible).
How this fits the rest of the stack
The infrastructure question is a small piece of a larger pattern: the team’s runtime, storage, database, secret store, logs, and deployment platform are all parts of the same platform. The right answer is to model the full stack before the project ships, not after. The RunxBuild hosting calculator is the right place to do that exercise — pick the runtime, the memory tier, the storage, the secret store, and the egress, and the calculator shows what the deploy actually costs at the team’s actual usage.
Useful related references:
FAQ
What is a SQL Managed Instance?
A Platform-as-a-Service relational database — the team gets a managed Postgres, MySQL, or SQL Server without operating the server, the OS, the backups, or the replication.
Is a managed database worth the cost?
For a team that does not have a dedicated DBA, yes. The right answer is the managed instance for a team that wants to focus on the application, not the database.
What is the difference between a managed instance and a serverless database?
A managed instance runs continuously (the team pays for the instance). A serverless database (Neon, PlanetScale) scales to zero (the team pays for the actual usage).
What is the difference between Azure SQL Managed Instance and AWS RDS?
Azure SQL Managed Instance is for SQL Server compatibility (lift-and-shift from on-prem). AWS RDS is for any relational database (Postgres, MySQL, SQL Server, MariaDB, Oracle).
How do I migrate to a managed instance?
For a small database: pg_dump (Postgres) or mysqldump (MySQL) and restore. For a large database: a logical replication or a managed migration tool (AWS DMS).
Does a managed instance have automatic backups?
Yes — daily snapshots and point-in-time recovery (typically 7-35 days retention). The right answer is to enable the long-term retention for compliance.
Can I install a custom Postgres extension on a managed instance?
Depends on the provider. The right answer is to check the provider’s supported extensions list. The wrong answer is to assume the extension is supported.
Is a managed instance more expensive than self-hosted?
For a small team, yes. For a team that has a dedicated operator, the operator time is the cost — a managed instance is cheaper if the operator is paid more than the per-hour difference.