Updated: November 2026
Almost every enterprise application depends on a database. A slow database, a missing backup or a version left behind on patches can quickly turn into business disruption. For many IT teams, the real question is: "Who will manage the database, and under which model?" In this guide we explain what database management covers, how in-house management differs from DBaaS (Database as a Service), and which criteria to consider when making a choice.
What does database management cover?
Database management is a much broader operational responsibility than installation. It typically includes:
- Installation and configuration: Engine version, parameters, storage and network settings.
- Backup and restore: Backup frequency, retention period and restore testing.
- Patch and version management: Security patches, minor version upgrades and planned upgrades of versions reaching end of support.
- Performance management: Slow query analysis, indexing strategy and resource sizing.
- Access and security: User and role management, encryption and audit logs.
- High availability: Replication, failover and disaster recovery scenarios.
- Monitoring and incident management: Tracking metrics and alerts, responding to issues and root cause analysis.
Each of these areas requires knowledge, time and on-call capacity. The model you choose determines how much of this workload stays with your team.
What is DBaaS? How is responsibility shared?
In the DBaaS model, the database infrastructure and routine operational tasks are run by the provider. Installation, backup, patching and basic monitoring are usually the provider's responsibility. You keep control over the data model, queries, application-side access and business rules.
Exactly where the line is drawn varies by provider and service tier. That is why it is important for the contract to include a responsibility matrix that sets out in writing who does what.
In-house management vs DBaaS
| Area | In-house (self-managed) | DBaaS |
|---|---|---|
| Infrastructure and operating system | Your team | Provider |
| Backup and patching | Your team | Mostly the provider |
| Performance tuning | Your team | Shared; scope depends on tier |
| Schema and query design | Your team | Your team |
| Scaling | Hardware or virtual resource planning | Through the service plan |
| Cost structure | Hardware, licences and staff | Service fee and licensing model |
The in-house model can still make sense for highly specific configurations or well-established internal processes. DBaaS reduces the routine operational workload and lets your team focus on the application side.
Backup, patching and performance: how to read the scope
When comparing offers, get written answers to these questions:
- How often are backups taken, how long are they retained and where are they stored?
- Who performs restore tests, and how often?
- In which maintenance window, and through which approval process, are patches applied?
- For performance issues, does the provider look only at the infrastructure, or is query-level support also included?
Selection criteria
- Engine and version support: Are the engine, version and extensions your application uses included in the service catalogue?
- RPO/RTO targets: Are acceptable data loss (RPO) and the time to restore service (RTO) turned into written targets?
- Data location: Does the contract clearly state where the data is stored? This is critical under KVKK (Turkey's Personal Data Protection Law), GDPR and sector-specific regulations.
- Access model: What are the options for private network connectivity, VPN or public access?
- Monitoring and response: Are monitoring scope and incident response commitments defined separately?
- Exit plan: If you decide to leave the service, in which format and how quickly can you get your data back?
Database migration plan
Moving an existing database to DBaaS is not a one-step job. A sound migration usually goes through these stages:
- Inventory and compatibility analysis: Databases, versions, sizes and dependent applications are listed.
- Pilot migration: A trial is run in a test environment with a non-critical database.
- Synchronisation: Data is kept up to date through replication to shorten downtime.
- Planned cutover: Application connections are moved to the new environment in a predefined window.
- Validation and rollback plan: Data integrity and performance are checked; rollback steps are ready if problems arise.
Managed databases with Cloud Expert
For details of Cloud Expert's managed database service, supported options and scope, see our DBaaS page. If you want to handle database operations as part of wider IT operations, take a look at our IT Operations service.
Frequently Asked Questions
Should database management be done in-house or with DBaaS?
The decision depends on your team's database expertise, on-call capacity and number of databases. With in-house management, your team is responsible for installation, backup, patching and performance. With DBaaS, these routine operational tasks move to the provider and you focus on schema, query and access management. In both models, having the responsibility boundary written into the contract is decisive.
Which database engines can be run as a managed service?
Supported engines vary by provider and service catalogue. The most common in the market are PostgreSQL, MySQL/MariaDB, Microsoft SQL Server and Oracle. Before deciding, verify the version, extensions and licensing model your application uses against the provider's current catalogue, and run your tests in the target environment.
How are backup and recovery targets (RPO/RTO) set in DBaaS?
RPO is the acceptable period of data loss; RTO is the time needed to restore the service. These values depend on backup frequency, replication type and the chosen service level. Before signing the contract, translate your business requirements into written targets and run restore tests regularly.
Where is our database data stored, and what should we check for KVKK?
The location where data is stored should be clearly stated in the service contract. Under KVKK, check the data processor role, access permissions, encryption and audit logs. It is recommended that the final compliance assessment is carried out together with your legal and information security teams.
How long does it take to migrate our existing database to DBaaS?
The duration depends on data volume, engine version, the number of dependent applications and the permitted downtime window. The general flow is inventory analysis, pilot migration, synchronisation through replication, planned cutover and validation. A rollback plan should be prepared for every step.
How do monitoring and incident response work with DBaaS?
Database metrics can be monitored 24/7; however, incident response times are a separate concept and vary according to the chosen service tier. Which alert is handled by whom, the response tiers and the escalation path should be clarified in the contract.
Related Services
Explore the Cloud Expert services related to this topic: