// Remote DBA services
Remote DBA services for PostgreSQL and open source databases.
DBA as a service, on your infrastructure.
OSSeva engineers act as your database administrators: monitoring, incident response, patching and upgrades around the clock, with a 15-minute P1 response. Choose a co-managed engagement next to your own DBAs, or a fully managed one. The databases stay on your servers, in your cloud account or on your Kubernetes clusters.
Last reviewed
Co-managed or fully managed: which remote DBA model fits?
Pick co-managed if you have DBAs who should keep the decisions. Pick fully managed if you have none. Both run through OSSeva Operate and are priced per cluster.
Co-managed DBA
You have DBAs and want them to stop carrying the pager and the patch work.
Your DBAs keep schema design, query work, change approval and the knowledge of your applications. Our engineers take the operational layer: monitoring around the clock, incident response, patching, rolling upgrades and capacity reviews. Everything runs through your change process.
Fully managed DBA
You have no DBA, or none who can carry the pager.
OSSeva Operate acts as your DBA team. A named senior engineer owns your account, we write the runbooks for your clusters before we go live, and we handle the day-to-day database operations. You still approve changes that touch your applications.
| Who does what | Co-managed | Fully managed |
|---|---|---|
| 24/7 monitoring and incident response | OSSeva | OSSeva |
| Patching and rolling upgrades | OSSeva executes, your DBAs approve the window | OSSeva |
| Backups, restore and point-in-time recovery tests | OSSeva monitors and tests, you own retention policy | OSSeva |
| Capacity planning and quarterly review | Shared | OSSeva |
| Schema design and query changes | Your DBAs | Your developers, with OSSeva advice |
| Change approval for your applications | Your DBAs | You |
What response times does a remote DBA from OSSeva commit to?
The same targets as OSSeva Operate, which delivers this service. Every account has a named senior engineer, and OSSeva patches Critical CVEs (CVSS 9.0 and above) within 48 hours and High within 7 days.
| Priority | Definition | Response | Resolution target |
|---|---|---|---|
| P1 | Production down / data loss risk | 15 minutes | 4 hours |
| P2 | Significant degradation, no immediate outage | 1 hour | 8 hours |
| P3 | Non-critical issue, workaround available | 4 hours | 2 business days |
| P4 | Question, advisory, enhancement request | 1 business day | Scheduled sprint |
What does a month with a remote DBA look like?
Most of the work is routine and invisible: that is the point. These are the recurring tasks Operate covers for a database estate.
Around the clock
- Replication, failover and backup monitoring on every cluster in scope
- Alert triage with a remediation path for each alert, written during onboarding
- P1 and P2 incident response, followed by a post-mortem and a prevention plan
Through the month
- VACUUM and analyze tuning, and Patroni, repmgr and consensus store quorum checks for PostgreSQL
- Patch deployment coordination, with fixes rolled out in your maintenance windows
- Rolling upgrades carried out node by node, and major version upgrades run with your team
- Disaster recovery runbook validation and point-in-time recovery tests
Each quarter
- Quarterly business review of incidents, capacity trends and the version plan
- Capacity planning and scaling recommendations
Example monthly report outline
Example only. This is not a customer report. The report format and cadence are agreed during onboarding.
1. Summary
Clusters in scope, incidents by priority, response times against the SLA table, changes made.
2. Availability
Replication state and lag, failovers (planned and unplanned), backup and restore results for each cluster.
3. Incidents
One line per incident with its priority, cause, resolution and follow-up action. Links to post-mortems.
4. Changes and patches
Minor and security patches applied, upgrades completed, upgrades planned for the next window.
5. Performance and capacity
Disk and connection headroom, slow query and autovacuum observations, growth since the last report.
6. Version and support status
Each cluster's version against its community end-of-life date, and what covers it after that date.
7. Recommendations
Open items ranked by risk, each with an owner on your side or ours.
What does a DBA runbook look like?
Operate writes the runbooks for your environment before we take the pager, so every alert has a remediation path. Below is a generic excerpt in the same shape, with placeholders and no customer data. Yours would carry your hostnames, thresholds and escalation contacts.
RUNBOOK EXCERPT (generic example, placeholders in <angle brackets>)
Alert: replica lag above threshold, PostgreSQL streaming replication under Patroni
Severity: P2 by default. Raise to P1 if no replica can take over as primary.
1. Confirm the alert is real
patronictl -c <patroni-config> list
-- on the primary:
SELECT application_name, state, write_lag, flush_lag, replay_lag
FROM pg_stat_replication;
2. Find where the lag builds up
-- on the lagging replica:
SELECT now() - pg_last_xact_replay_timestamp() AS replay_delay;
-- long queries on the replica that block WAL replay:
SELECT datname, confl_snapshot, confl_lock FROM pg_stat_database_conflicts;
3. Check that the primary is not holding WAL for a stuck slot
SELECT slot_name, active,
pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained_wal
FROM pg_replication_slots;
4. Decide
- Network or disk saturation on the replica: engage <infrastructure contact>.
- Replay blocked by a long read query: agree with <application owner> before cancelling it.
- Slot retaining WAL with no consumer: confirm with <customer DBA> before dropping the slot.
- Replica cannot catch up: rebuild it from backup (see rebuild runbook), do not fail over to it.
5. Close
Record cause and action in the ticket. A post-mortem is written for P1 and any repeat P2.Which databases are covered, and what is out of scope?
OSSeva supports PostgreSQL first, then the other open source engines this site lists: MySQL, MariaDB, MongoDB, Redis and Valkey, Elasticsearch and ClickHouse. Every engine runs self-managed on your own servers, cloud account or Kubernetes. OSSeva does not support Microsoft SQL Server or Oracle Database, and it does not host databases.
In scope
- PostgreSQL first, including end-of-life versions
- MySQL, MariaDB and MongoDB under OSSeva Operate
- Other open source engines from the list above, agreed case by case
- Your servers, your cloud account or your Kubernetes clusters
Out of scope
- Microsoft SQL Server
- Oracle Database
- Hosting: OSSeva does not host databases
Moving off SQL Server or Oracle? See SQL Server to PostgreSQL and Oracle to PostgreSQL.
What is the difference between remote DBA services and managed database services?
A remote DBA service is about the role: who carries the pager, runs the upgrades and answers for the database. Managed database services describe the operating model, which here is self-managed databases on your infrastructure, run by OSSeva. On this site both are delivered by OSSeva Operate. For the model compared with cloud database services, read managed database services.
Managed database services →Do you replace our DBAs or work with them?
Either, depending on the engagement model above. In a co-managed engagement your DBAs keep the decisions and the application knowledge. In a fully managed one OSSeva Operate is the DBA team.
How OSSeva works with an in-house DBA team →Can a remote DBA look after end-of-life database versions?
Yes. Operate includes patched builds for end-of-life versions, so the version you run today stays covered while an upgrade is planned. OSSeva patches Critical CVEs (CVSS 9.0 and above) within 48 hours and High within 7 days.
PostgreSQL end-of-life continuation →Is there a way to try the service before signing?
A fixed-scope database health check gives you a written report on your PostgreSQL, MySQL or MongoDB clusters before you decide on anything ongoing.
Database health check →How is a remote DBA service priced?
OSSeva Operate is priced per cluster, not per core, per GB or per node. The clusters in scope and the technologies on them set the quote, and adding a technology later goes onto the same contract and renewal date. Contact us for a quote, or compare your current spend with the database support cost calculator. How pricing works is on the pricing page.
Frequently asked questions
What is DBA as a service?
DBA as a service means a provider's engineers do the work a database administrator would do for you: monitoring, incident response, backups and recovery tests, patching and upgrades. With OSSeva the databases stay on your own servers, cloud account or Kubernetes, and OSSeva does not host them.
Which databases does the remote DBA service cover?
OSSeva supports PostgreSQL first, then the other open source engines this site lists: MySQL, MariaDB, MongoDB, Redis and Valkey, Elasticsearch and ClickHouse. Every engine runs self-managed on your own servers, cloud account or Kubernetes. OSSeva does not support Microsoft SQL Server or Oracle Database, and it does not host databases.
Is PostgreSQL the main focus?
Yes. PostgreSQL is where we start, and the patterns on this page (Patroni and repmgr failover, VACUUM and analyze tuning, point-in-time recovery tests) are PostgreSQL ones. MySQL, MariaDB and MongoDB are covered under OSSeva Operate. Other engines are agreed case by case.
What response times does the remote DBA service have?
P1 incidents (production down or data loss risk) get a 15-minute response with a 4-hour resolution target. P2 gets a 1-hour response and an 8-hour resolution target. The full table is on this page and on the OSSeva Operate page.
Do you host our databases?
No. OSSeva does not host databases. Our engineers work through the access you grant, on your servers, in your cloud account or on your Kubernetes clusters, and the data stays yours.
Do you support SQL Server or Oracle Database?
No. OSSeva does not support Microsoft SQL Server or Oracle Database. If you plan to move off them, the migration to PostgreSQL pages cover that route.
How is the remote DBA service priced?
OSSeva Operate is priced per cluster. The clusters in scope and the technologies on them set the quote. Contact us for a quote, or compare your current spend with the database support cost calculator.
Hand us the pager, keep the decisions.
Bring your cluster list to a discovery call. We confirm the engagement model, scope the clusters and send a quote priced per cluster.