GitLab on RDS, Cloud SQL or Azure PostgreSQL

Running GitLab on managed PostgreSQL: what your team must decide first

Running GitLab on a managed PostgreSQL service is a supported pattern to evaluate, but it is not a drop-in replacement for the database that ships with the Linux package. The GitLab release, the PostgreSQL major version, the admin role the provider grants and the extensions GitLab requires decide whether a given managed service fits. Confirm all four against the GitLab release you plan to install before you size anything or sign a contract. Teams usually choose a managed service because they want the database patched, backed up and replaced on hardware failure by the cloud provider, so their platform engineers spend less time on PostgreSQL operations. The bundled PostgreSQL in the Linux package is the simpler default for a single-node or small instance. GitLab's reference architectures place stateful services such as PostgreSQL on VMs or managed services rather than inside Kubernetes, so a managed database is a natural fit for a Cloud Native Hybrid layout where the stateless components run on Kubernetes. That split is a deliberate design choice, and it moves responsibility for failover and backup tooling to the provider and to your team.

The first decision is the PostgreSQL major version. Check the GitLab installation and requirements documentation for the versions your release supports, then compare them with the provider's offered versions and the support end dates in the PostgreSQL versioning policy. Ask the provider which GitLab-required extensions are on its allow list and whether the database role it gives you can create them, because GitLab's own install steps and upgrades assume certain privileges. Ask which role owns the GitLab database and whether migrations run under that role or a separate one. Finally, confirm what the provider does during a major version upgrade, since that work will fall on your team's change calendar. Record each answer in writing, since they become the acceptance criteria for the database build.

How Amazon RDS, Cloud SQL and Azure Database for PostgreSQL differ for GitLab

Amazon RDS for PostgreSQL runs the host and engine for you, while your team manages databases, roles and settings through the master user and parameter groups. For GitLab, the first check is whether the master user holds the privileges that GitLab's database setup and upgrade steps expect. The master user is a provider-managed account with elevated rights, not a superuser, so some steps may need to run under a different account.

Master user privileges: Confirm in GitLab's current database requirements which privileges the installation and upgrade steps need, and whether they must be granted before the first run.
Extension enablement: Extensions that GitLab uses must be available on the instance and created by a role with the right privilege. Take the list from GitLab's documentation for your release, since older guides may be out of date.
Migration accounts: Schema migrations run during upgrades under the application's database user. Confirm which steps need the master user and plan the window in which that access is granted and then removed.
Parameter groups: Settings that GitLab documents are changed through parameter groups, and some changes need a restart. Record each change in your change log so the configuration can be rebuilt.
Major version support: RDS offers PostgreSQL major versions on its own schedule, and the PostgreSQL community support window applies regardless of provider. Match the version to the PostgreSQL versions your GitLab release supports.

Confirm the current role model, extension availability and parameter behavior in the AWS documentation for your engine version before you choose the instance class and storage.

Which database hosting option fits which GitLab deployment

This table compares the bundled Linux package PostgreSQL, self-managed PostgreSQL on virtual machines, and a managed PostgreSQL service on AWS, Google Cloud or Azure across operational responsibilities. Read each row as a question you must answer before the build starts. The main takeaway is that a managed service shifts patching and backups to the provider, but automatic failover and GitLab-side settings still need planning.

Decision area	Bundled Linux package PostgreSQL	Self-managed PostgreSQL on VMs	Managed service (RDS, Cloud SQL, Azure Flexible Server)
Who patches and backs up the database	Your team, through the GitLab package and the host operating system	Your team, for PostgreSQL binaries, operating system and backup tooling	Provider handles patching windows and automated backups; you confirm retention and restore options with the provider
How major upgrades are run	Planned with GitLab upgrade stops and a database upgrade step you test in staging	Run with pg_upgrade, dump and restore, or logical replication, all executed by your team	Run through the provider's upgrade process; confirm downtime, rollback and extension compatibility before scheduling
How replicas and failover are handled	Not a supported high availability layout for most multi-node designs; plan external tooling if needed	Hot standbys, synchronous or asynchronous replication, with failover tooling you select and operate	Provider-managed standby options exist on some tiers; confirm failover behavior, recovery time and read replica support for GitLab
Automatic failover	Not provided by PostgreSQL itself; requires external tools	Not provided by PostgreSQL itself; a tool such as Patroni or a similar product must detect failure and promote a standby	Provider may offer it, but confirm whether it is automatic, which events trigger it and whether GitLab reconnects cleanly
Required admin roles and extensions	Created by the package; no separate role setup for most installs	Your team creates the GitLab database role and grants needed privileges	Provider admin role is restricted; confirm the role GitLab needs and which extensions must be allow-listed
Connection pooling	Not included in the package layout you typically use	Deploy PgBouncer or equivalent if connection counts require it	Confirm whether the provider offers pooling, and whether GitLab connection limits need adjustment
What the GitLab installation must be told	Nothing beyond the bundled defaults in the configuration file	Host, port, database name, role, password, SSL and pooling settings in the configuration file	External database host, port, credentials, SSL mode and any required extensions; confirm the exact keys in the GitLab documentation for your version
Backup and restore compatibility	GitLab backup task covers the bundled database; check the backup procedure for your version	Use pg_dump or pg_basebackup versions that match the server; test restores regularly	Use provider snapshots and point-in-time recovery; confirm pg_dump client versions match the managed server before running GitLab backup

Matching PostgreSQL major versions to each GitLab release

The GitLab release you install decides which PostgreSQL major versions you may run, so the database plan starts with the GitLab version you are targeting. Before you provision an RDS, Cloud SQL or Azure Database for PostgreSQL instance, open the requirements for that release and record the PostgreSQL majors it accepts. Then check the provider's catalog for the same major in your region. The PostgreSQL community supports version 18 until November 14, 2030, 17 until November 8, 2029, 16 until November 9, 2028, 15 until November 11, 2027 and 14 until November 12, 2026. Versions 13 and earlier are unsupported. PostgreSQL versioning policy explains how these windows are set. Choose a major that stays inside its window for the whole period you expect to run that GitLab release.

GitLab ships a major release once a year, and GitLab 20.0 is planned for May 2027. Upgrades must pass through required upgrade stops, which since GitLab 17.5 fall at versions x.2, x.5, x.8 and x.11, for example 18.2, 18.5, 18.8, 18.11, 19.2, 19.5, 19.8 and 19.11. Write the database plan against those stops. At each stop, confirm the PostgreSQL majors GitLab accepts, because a target stop may require a newer major than the one you run today. If it does, the PostgreSQL upgrade becomes a prerequisite of that GitLab step, and both changes need a rollback point and a tested restore before you start. Use the GitLab upgrade paths documentation as the authority for each stop.

Treat the database as a dependency with its own calendar. GitLab's maintenance policy backports bug fixes only to the current stable release and security fixes to the previous two monthly releases, so an instance that lags behind the upgrade stops also lags on patches. Managed services publish their own version catalogs and retirement dates, which can differ from the community windows above. Ask each provider which PostgreSQL majors it offers in your region, how long each stays available and what happens to instances on a retired major. Write those dates next to the GitLab stops in one plan, and name the database upgrade as a prerequisite in the GitLab upgrade runbook.

How to provision and connect a managed PostgreSQL instance for GitLab

This sequence takes a managed PostgreSQL service from version selection to a GitLab instance that connects over TLS, passes its health checks and has proven it can restore a backup.

Confirm GitLab release and PostgreSQL version
Before you create anything, check the GitLab release you plan to install against GitLab's upgrade paths and installation documentation, and confirm which PostgreSQL major versions that release supports. Then check the PostgreSQL support window for each candidate major version, since a version nearing end of support will force an upgrade shortly after go-live. Record the GitLab release, the PostgreSQL major version and the provider's available versions in a short change record. You know this step is done when the record names one GitLab release and one PostgreSQL major version that both documents accept, and the provider offers that version in your target region.
Create the instance in a private network
Your platform or cloud team creates the managed PostgreSQL instance in the same network as the GitLab host or nodes, with no public endpoint, and restricts inbound access to the GitLab security group or subnet. Confirm which settings the provider makes permanent after creation, such as the network, the engine version family and encryption keys, and which can be changed later. Enable automated backups and record the retention setting your policy requires. You know this step is done when a host outside the GitLab subnet cannot open a connection to the database port, and a host inside it can.
Create the GitLab database and role
Create a dedicated database and a login role for GitLab, and grant only the privileges the provider's admin model and the GitLab documentation require for that role. Keep the provider's administrative account separate from the application role and store the application password in your secrets manager, not in a configuration file in version control. Confirm with the GitLab database documentation whether the role needs ownership of the database or specific privileges, because providers restrict some superuser operations. You know this step is done when you can log in as the GitLab role from the GitLab host and run a simple read query, and the role cannot perform the administrative actions you withheld.
Allow-list required extensions
Add the extensions GitLab requires to the provider's allow list through its parameter or extension settings, then create them in the GitLab database using the role that the provider permits. Check the exact extension names against GitLab's current database requirements for your release rather than relying on a list from a previous version. Some providers need a restart or parameter change before an extension can be created. You know this step is done when a query listing installed extensions in the GitLab database shows each required extension with the expected version.
Enforce SCRAM password authentication
Set the instance's password encryption parameter to SCRAM so that new and changed passwords are stored with SCRAM hashes, and confirm that the GitLab role's password was set after that change. Check the authentication rules that the provider exposes and remove any method weaker than SCRAM for connections from the GitLab network. PostgreSQL has deprecated MD5 password authentication in favor of SCRAM, so a legacy hash left in place is a finding to fix before go-live. You know this step is done when the role's stored password is a SCRAM verifier and a connection attempt using an MD5-only client setting is refused.
Connect GitLab over TLS
Download the provider's CA bundle, place it on the GitLab nodes, and configure GitLab's PostgreSQL connection settings to require TLS and verify the server certificate against that bundle. Set the database host to the provider endpoint name that matches the certificate. Keep the connection settings in the GitLab configuration file and apply them with the reconfigure command. You know this step is done when a TLS connection from the GitLab host reports an encrypted session with certificate verification, and a connection with verification forced to fail is rejected.
Run reconfigure and health checks
Run GitLab's reconfigure command so the new database settings take effect, then run GitLab's built-in health and check tasks, including the database migration status and the application check. Review the output for connection errors, missing extensions and pending migrations, and fix each before you open the instance to users. Record the output as your baseline for future upgrades. You know this step is done when the reconfigure run completes without errors, the health checks report the database as available and the application check reports no failures.
Run a test restore
Take a backup of the GitLab database using the procedure in GitLab's backup documentation, then restore it into a separate managed instance created for testing. Compare the restored row counts or a checksum on key tables, then start a throwaway GitLab instance against the restored database to confirm it loads. Use the same PostgreSQL major version for the test restore, or confirm that your restore tool supports the version pairing you use. Keep the test instance isolated from production credentials. You know this step is done when the restored database matches the source on the agreed checks and the test GitLab instance reaches its login page.

Securing the database connection, credentials and backup path

A managed PostgreSQL instance holds every GitLab project, merge request and CI record, so its network path, login model and backup copies carry the same sensitivity as the GitLab instance itself. The cards below cover the controls to set before GitLab first connects, and the provider-specific settings you should confirm with each cloud service.

Private networking without a public endpoint

Place the database in private subnets reachable only from the GitLab nodes and the security groups or firewall rules that serve them. Disable any public endpoint, and confirm that the GitLab application and Sidekiq hosts are the only sources allowed on the PostgreSQL port. Ask your provider how private connectivity is set up and which default network paths it leaves open.

TLS in transit and encryption at rest

Require encrypted client connections so GitLab rejects plaintext sessions to the database, and set the matching SSL mode in GitLab's database configuration. Confirm with your provider that storage encryption is enabled, which key service manages it, and whether snapshots and replicas inherit the same key. Both settings should be verified after the first connection, not assumed from the console.

Least-privilege roles and rotated passwords

Keep the GitLab application login separate from the administrative role your provider uses to create databases and extensions. GitLab's database user should own only what it needs, and the provider's master role should not be used for daily operation. Plan a rotation schedule for the GitLab password and record where the secret is stored, because a rotation that GitLab does not pick up will stop the instance.

SCRAM authentication and MD5 retirement

Configure password authentication to use SCRAM, and do not create new users with MD5 hashes. PostgreSQL 18 deprecated MD5 password authentication in favor of SCRAM, so a database that accepts MD5 today will need to change before a future major upgrade. Check the server setting for password encryption and the pg_hba.conf rules that your provider exposes, and confirm the same setting on any read replicas.

Encrypted backups and controlled backup storage

Database snapshots and logical dumps contain the same repositories and secrets as the live database, so backup storage needs the same access control as production. Encrypt dumps before they leave the GitLab network, restrict who can restore, and keep backup storage in a separate account or subscription where possible. Test restores with the exact pg_dump client version that matches your server, because a mismatched client can refuse to dump.

Audit logging of connections and changes

Enable the provider's audit and connection logging so administrative actions, role changes and extension installs are recorded. Decide where logs go, who can read them, and how long they are kept, and confirm that the GitLab application's own logs do not capture credentials. Ask your provider which log categories are available for your engine version, since the set differs between services.

Why pg_dump compatibility decides how GitLab backups are restored

A GitLab backup is only as useful as the restore you have rehearsed, and with a managed PostgreSQL service the database dump is the part most likely to fail at the moment you need it. The restore must run against a PostgreSQL major version that the dump tooling can read and write, and that version must sit inside the range your GitLab release supports. Confirm both before go-live: the PostgreSQL major version your provider offers, the pg_dump and psql client version on the host that runs your backup job, and the PostgreSQL version your target GitLab release expects in its documentation. Treat a mismatch between the client and server as a restore risk to test, not an assumption to accept.

PostgreSQL's upgrading documentation describes three major-upgrade paths: dump and restore with pg_dumpall, in-place conversion with pg_upgrade, and logical replication between major versions. Dump and restore is the simplest to reason about and the slowest for large databases. pg_upgrade needs the old and new server binaries available to the same job, which a managed service does not expose to you, so ask your provider whether it is offered as a supported path. Logical replication is the option for a short cutover, but it requires the provider to allow the replication settings and the publication and subscription setup on the managed instance. Each path has different admin role and privilege requirements, so confirm them against the provider's own documentation rather than assuming the self-managed steps apply.

Dumps alone give you a restore point at the time the dump ran. For a recovery point between dumps, PostgreSQL's continuous archiving and point-in-time recovery documentation describes shipping WAL archives and replaying them to a chosen time. Whether your managed service exposes base backups, WAL retention and point-in-time restore is a provider feature, so ask for the retention window and restore procedure in writing. Finally, check GitLab's backup and restore documentation for its guidance on external databases and confirm that procedure works with your provider's restore process. Run a full restore into a separate instance and record the steps and timings before you rely on the plan.

Limits to confirm before you commit to a managed database

A managed PostgreSQL service removes some operations work but also removes some levers you would have on a server you control. The cards below cover the points to verify with the provider and with GitLab before you build, so that the database choice does not block install, upgrades or recovery later.

Superuser restrictions and setup steps

Managed services do not give you a true superuser account, so the admin role the provider offers may lack privileges that a GitLab setup step expects. Confirm with the GitLab install documentation for your release which statements need elevated rights, then check whether the provider's role can run them or whether you need a documented workaround. Ask the provider in writing what the admin role cannot do.

Extensions and allow-listing

GitLab needs specific PostgreSQL extensions in some releases, and each provider controls which extensions can be enabled. Build a list of the extensions your GitLab release requires, then check whether each one is on the provider's allow-list for the PostgreSQL major version you plan to run. A missing extension discovered during install is a common reason for a rebuild.

Connection count and PgBouncer

Every GitLab process holds database connections, so the total grows with the number of Puma, Sidekiq and supporting workers across your nodes. Compare the provider's maximum connection limit for your instance size against your planned process count. Where the margin is thin, plan a connection pooler such as PgBouncer in front of the database and confirm that your GitLab release supports the pooling mode you choose.

Failover and recovery time

Managed high availability options differ in whether failover is automatic, how long it takes, and whether the standby is readable. PostgreSQL itself does not detect a failed primary or promote a standby, so the provider's managed failover is the mechanism you rely on. Ask for the documented failover time, the recovery point for point-in-time restore, and how GitLab reconnects after a switch. Set your recovery time objective against those figures, not the marketing summary.

Provider version calendar

Each provider offers a set of PostgreSQL major versions and retires them on its own schedule, which may differ from the community end-of-life dates. Confirm which major versions the provider offers, when it plans to retire the one you deploy, and whether it forces an upgrade. Compare these dates with the PostgreSQL support windows, and check that the GitLab release you plan to run supports that major version.

Backup tooling and pg_dump compatibility

Managed services take their own backups, but GitLab's backup task and your restore tests depend on a pg_dump client that matches the server's major version. Confirm which client version your backup host runs, whether the provider lets you take logical dumps, and how long the provider retains automated backups. Test a restore into a separate instance before relying on either method.

Questions teams ask before running GitLab on a managed database

What drives the cost and effort of running GitLab on a managed database?

The main drivers are the database instance size and storage, the user count and CI load that set the size of the GitLab nodes, and the engineering time to build and test the setup. Managed database charges recur every month and grow with instance class, storage, backup retention and any standby or high availability option you turn on. Compute, object storage and network traffic also recur and are billed by your cloud provider. Engineering work is mostly one-time: provisioning, roles, configuration, a migration rehearsal and a runbook. Ask for a quote that separates one-time build and migration work from recurring cloud charges and any ongoing support retainer. Ask for the assumptions behind each line, including user count, expected CI volume and retention targets. Take infrastructure prices from your provider's pricing calculator, and take engineering prices from the written scope.

Can our team run GitLab on a managed database without outside help?

Yes, if your team already operates GitLab, manages the cloud account and has tested database restores before. The hardest parts are usually the provider-specific admin roles, the extension list, the network path from GitLab nodes to the database and a rehearsal that proves a restore works before cutover. Teams that have not restored GitLab recently often find these gaps during the cutover window. An outside partner can plan and implement the work under a fixed-scope agreement with written deliverables, or work alongside your staff and hand over runbooks. DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure. Ask any partner how they will test restores, what knowledge transfer is included and which tasks stay with your team after handover.

How long does a migration from the bundled database take?

No duration can be fixed in advance, because the time depends on database size, the downtime window you accept, the migration method and the number of rehearsals you need. A dump and restore needs downtime for the full copy, so the time grows with data size and restore speed. Logical replication can reduce cutover downtime to several seconds for major PostgreSQL upgrades, according to PostgreSQL's upgrading documentation, but it adds setup, monitoring and validation work before cutover. Other drivers include matching roles and extensions, object storage settings for large artifacts and the number of GitLab nodes that must point at the new endpoint. Ask for a plan that names the method, the rehearsal count, the cutover steps and the rollback point.

What does the migration need from our cloud and GitLab administrators?

Cloud administrators provide the network design and access. This includes a private network path between the GitLab nodes and the managed database, firewall or security group rules, the provider's server configuration with the required extensions enabled, an administrative account for provisioning and key management for encryption at rest. GitLab administrators provide the configuration: database connection settings in the Linux package or Helm chart, the list of GitLab nodes, the backup schedule and access to the current instance for rehearsals. Both teams approve the cutover window, the connection change and the rollback steps. Ask who holds each credential, how secrets are rotated and who signs off each change before it goes to production.

How do GitLab upgrades change the database plan?

Each GitLab upgrade can change the PostgreSQL version your target release supports, so the database plan must follow the GitLab upgrade path. GitLab requires upgrades to pass through required stops, which since GitLab 17.5 fall at versions x.2, x.5, x.8 and x.11, for example 18.2, 18.5, 18.8, 18.11, 19.2, 19.5, 19.8 and 19.11, according to GitLab's upgrade paths documentation. Check the PostgreSQL version each stop requires before you schedule it. A PostgreSQL major upgrade on a managed service is a separate project with its own rehearsal, backup point and rollback plan. Confirm with your provider which upgrade method it supports, the downtime it implies and whether your extensions carry over to the new version.

Which PostgreSQL major version should a managed database run?

Choose a version that your target GitLab release supports and that remains inside PostgreSQL's support window for the years you plan to run it. PostgreSQL 18 was first released on September 25, 2025, and is supported until November 14, 2030. Version 17 is supported until November 8, 2029, version 16 until November 9, 2028, version 15 until November 11, 2027 and version 14 until November 12, 2026. Versions 13 and earlier are no longer supported. PostgreSQL releases a major version about once a year and supports each one for five years, so the support end date should set your upgrade schedule. Managed providers may not offer the newest major version immediately, so confirm which versions your provider offers before you commit.

Will a pg_dump backup from a managed database restore cleanly into GitLab?

Test it before you rely on it, because managed services can restrict superuser access, and that can block some roles, extensions or dump options on restore. Keep the restore matched to the GitLab version that produced the backup, as GitLab's backup and restore procedure requires. For PostgreSQL itself, major upgrades can use pg_dumpall and restore, pg_upgrade or logical replication, according to PostgreSQL's upgrading documentation. Run a restore into a separate database with the same extensions and roles, then check the GitLab application after the restore. Ask for the pg_dump client version used, the extension list and the written result of the restore test. Also confirm that object storage data is backed up separately, since the database dump does not contain it.

Does a managed database remove the need to plan high availability?

No. A managed service can offer standby capacity, but PostgreSQL does not detect a failed primary or notify a standby by itself, so automatic failover depends on the provider or external tools. Confirm the failover time, whether standbys serve read traffic, the replication mode (synchronous or asynchronous) and the point-in-time recovery retention. GitLab's reference architectures generally recommend a high availability strategy from 3,000 or more users, and the Cloud Native Hybrid pattern runs stateful services on virtual machines or managed services. GitLab documents that running PostgreSQL and Redis inside Kubernetes is not supported. For disaster recovery in another region, GitLab Geo is a separate feature that requires a paid subscription tier.

What drives the cost and effort of a managed database setup

A managed PostgreSQL service removes some operating work but adds design, migration and testing work that someone must price. The cards below separate who is paid for each piece, which costs recur, and which factors push effort up, so the written scope you request can be compared line by line.

Design and provisioning work

Sizing the instance class, storage, networking, parameter groups and high availability option is a one-time design task, whether your team or a partner performs it. Ask the scope to name the provider, the GitLab release the database must support, and who owns the Terraform or console steps. Confirm which PostgreSQL major version the provider offers for your chosen GitLab release before design starts.

Migration and cutover effort

Moving an existing Omnibus PostgreSQL data set into a managed service is usually the largest one-time cost. The effort depends on database size, how long the GitLab instance can stay in maintenance mode, and whether a logical replication path is used to shorten the window. Ask the quote to state the rehearsal count, the cutover runbook and the rollback plan.

Testing and restore verification

A managed database still needs proof that GitLab works against it and that backups restore cleanly with the provider's tooling. This includes upgrade testing, a restore into a separate instance and checks of required extensions. Request the test list in writing, including who signs off on the restore result, because this step is easy to underprice.

Recurring managed database charges

Instance hours, storage, backup retention, high availability replicas and data transfer are billed by the provider every month, and your cloud account pays them directly, not the implementation partner. These charges grow with database size and replica count. Ask the quote to separate the provider's recurring bill from any support or retainer fee, so the two are not confused in budgeting.

Factors that raise effort

Several factors increase work: a large database that takes long to dump or restore, a short cutover window, a multi-zone or multi-region high availability design, and compliance evidence that must show configuration, access and backup records. Each one adds design or test hours. Ask the scope to list which of these apply to your environment and what evidence each one produces.

How DeployOpen scopes and delivers a GitLab database implementation

DeployOpen plans and builds the managed PostgreSQL layer behind self-managed GitLab as part of a written scope, inside your own cloud account or data center. The work covers provider roles, extensions, version alignment with each GitLab release, backups and the upgrade plan, so your team knows what it owns after go-live.

How we scope

Confirm which GitLab release and PostgreSQL major version you plan to run, and map them against the upgrade stops that apply.
Document the admin roles, extensions and network paths your chosen provider requires for the GitLab database user.
Agree in writing which backup method, restore test and maintenance window belong to the deliverables and which stay with your team.

How we build

Provision the managed PostgreSQL instance, parameter settings and private networking in your account, following your change process.
Configure GitLab against the managed endpoint, then check connection pooling, authentication method and TLS settings with test traffic.
Run a restore into a separate environment and confirm that a pg_dump taken from the managed service restores into the target version.

How we hand over

Deliver runbooks for version alignment, minor patching, major upgrade options and the required GitLab upgrade stops.
Provide a record of provider roles, extensions, parameter groups and backup retention so your auditors and operators can verify them.
Walk your database and platform engineers through restore steps and the escalation path between your team and the provider.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer that follows the GitLab and PostgreSQL release calendars.
Retainer scope, response expectations and the test cadence for restores are set in the written agreement, not assumed.
Ask any partner, including DeployOpen, to confirm the provider's current support terms and extension list for your region before you commit.