Managed vs Unmanaged Database: Which Should You Run

In a managed vs unmanaged database choice, the cloud provider runs the engine, patches and backups under a managed service. On a self-managed database, your own team runs them. This guide lists who carries each job. Then it gives the facts to gather about each database and a decision note to keep per database.

The reader here is an IT head or database lead with databases already running. For each one, the question is whether it moves to a managed service on AWS or Azure or stays self-run. Also, the managed vs self managed database question gets an answer per database, not one answer for the estate. Also, for more on that burden, see the upkeep a self-run database puts on a team.

Managed vs Unmanaged Database: Who Runs Each Job

A managed database service is one where the cloud provider installs, patches and backs up the engine. People sometimes call it database as a service. However, a self-managed database is one your team installs and runs on its own servers or on cloud virtual machines. The table below splits seven jobs between the two, with a provider documentation page behind each row.

Which Services the Table Covers

The table compares Amazon RDS on AWS with Azure SQL Database and Azure SQL Managed Instance on Azure. However, a standby copy is not a recovery plan, and how a standby copy differs from a recovery plan covers that line.

Signisys read both pages on 14 November 2026: the AWS Amazon RDS user guide and the Microsoft Learn Azure SQL Database overview.

Facts to Gather About Each Database

First, work through six facts for every database in turn. Each fact comes down to a question your own estate can answer.

Engine, Edition and Version in Use

Ask which engine and edition each database runs. Then ask whether the managed service on each cloud offers that engine and version today. For example, Amazon RDS states that feature support varies by Region and engine version. However, a version outside the list points to an upgrade first or to a self-managed database, and the gap belongs in the note for that database. Also, leave end-of-support dates to a separate check of your own, as they change.

Extensions, Agents and Server Settings

Next, ask which extensions, linked servers, scheduled jobs, backup agents or file system access the database relies on, and whether the application could change to do without any of them. Then check each against the supported extension and feature list of the service you are considering. Also, anything outside the list points to self-managed, or to a change in the application.

Managed vs Unmanaged Database Skills and the On-Call Rota

Ask who on the team tunes queries, reads recovery logs and answers night calls today. Then ask what happens when that person leaves. A dbaas vs self hosted decision is partly a decision about people. A managed service moves some of this work to the provider, but it leaves the query work with you.

Then write the names. A rota that depends on one person is a fact worth recording under either model.

Patch Windows and Recovery Targets

Then ask when the business allows downtime for patches, and how much data loss and downtime each database can bear. The first is the recovery point, meaning the age of the newest data you can restore. The second is the recovery time, meaning how long the database may stay down.

Then check whether the maintenance window and restore window of each service fit those answers. Azure SQL Database offers a maintenance window for eligible databases. Also, its backups restore to any point within the retention period.

Data Location, Country by Country

List each country the firm works in, such as India and each GCC country. For each, check the current region list of each cloud. Then check whether the managed service you want and its backups run in that region. Amazon RDS states that feature support varies by Region. Also, Microsoft publishes a supported regions list for Azure SQL Managed Instance. Finally, record the answer per database, as one customer table may need a country the others do not.

Exit Routes for a Managed vs Unmanaged Database

Finally, ask how data comes out of each option: native backup, export or replication. Ask also whether the engine is the same one you could run yourself, so a later move stays open. Microsoft states that a managed instance backup restores only to another managed instance. It can also restore to the SQL Server versions it names. This guide claims no lock-in either way. However, the answer belongs in the note for each database.

Cloud Virtual Machines as the Middle Ground

Next, cloud virtual machines sit between the two models. SQL Server on Amazon EC2 or on Azure virtual machines means the provider runs the hardware while your team still runs the engine, so it counts as self-managed. The RDS guide lists the customer as patching the database and operating system on Amazon EC2. Also, Microsoft offers an optional agent extension that schedules patching and backups on an Azure virtual machine. Then Amazon RDS Custom gives administrators access to the operating system and database environment while automating parts of the work. Also, it adds shared responsibility. However, Azure SQL Managed Instance stays a managed service. It offers near full SQL Server feature compatibility, including SQL Server Agent jobs and linked servers.

For a managed vs unmanaged database decision, ask which of the six facts these options answer. Then ask which they leave open. However, picking a cloud is a separate question and not covered here.

Managed vs Unmanaged Database Leanings for Five Sample Databases

Next, five sample databases show how the facts point. Then read each row as a lean to test against your own database, not a ruling.

Signisys working view: for a managed service, start with databases that need no operating-system access and run a supported engine. The basis is the table above. The jobs in its first four rows move to the provider with no change to the application.

Also, keep money out of this first pass. It compares jobs and facts, and your own figures can follow once you set the leans.

A Decision Note to Keep for Each Database

Keep one note per database. It records the engine and version, the extensions and agents, and the skills on hand. Also record the patch and recovery needs, the data location and the exit route. Then add the lean chosen and why, who agreed, what would reopen it, and the date.

Signisys working view: run some databases managed and keep others self-managed, instead of forcing one model on every database. The basis is that the facts differ from one database to the next, as the sample table shows.

With each lean set, the move itself once each lean is set covers the move. Also, the checks around the switch to the new database covers the switch.

Help fits when the facts point different ways, or when a vendor’s terms need a ruling. Signisys sells these services as an AWS and Microsoft partner. See help moving databases to managed services on AWS or Azure, cloud migration and modernization work and cloud and platform engineering support. A working session then reads through your decision notes, with no result promised in advance. No charge, with a fixed scope.

Managed vs Unmanaged Database FAQ