THE MINERVADB DIFFERENCE
Why Enterprises Trust MinervaDB for PostgreSQL Support
PostgreSQL has become the default system of record for modern enterprises — payment ledgers, order books, clinical records, telemetry stores, and the vector indexes behind AI features. That trust is well placed, but PostgreSQL rewards operational precision and punishes neglect quietly: bloat accumulates, the transaction ID horizon creeps forward, a replication slot fills a volume, and a plan regression turns a 3 ms query into a 3-second one. Enterprise-grade PostgreSQL Support exists to catch those failures long before your users do.
Your cluster is designed and operated by senior PostgreSQL DBAs who have recovered corrupted clusters, rebuilt broken replication, and tuned multi-terabyte workloads in production — never by junior staff learning on your time.
Our PostgreSQL Support team operates across every time zone. Severity-one incidents receive a 15-minute response backed by a written SLA, and you reach an engineer directly rather than a ticket queue.
We resell no licences and earn no cloud commissions. When we recommend Patroni over a managed service, or a smaller instance class than your vendor proposed, the only interest being served is yours.
One partner owns architecture, query tuning, replication, high availability, backup verification, security hardening, and version upgrades. No finger-pointing between vendors when replication breaks at 3 a.m.
We operate your PostgreSQL estate against explicit objectives for availability, replication lag, checkpoint duration, and p99 query latency — then report against them every month with the raw evidence attached.
Every change is documented, every runbook is yours to keep, and your engineers sit in on the diagnostic work. Our goal is a stronger internal team, not a permanent dependency.
POSTGRESQL ARCHITECTURE
How a PostgreSQL Instance Actually Behaves Under Load
Effective PostgreSQL Support starts with an accurate mental model of the engine. PostgreSQL is a process-per-connection system: the postmaster listens, authenticates, and forks a dedicated backend for every session, while a set of background workers handles checkpointing, dirty page writeback, WAL flushing, autovacuum, and archiving. Everything those processes share — the buffer cache, the WAL buffers, the lock table, the commit log — lives in a single shared memory segment sized at startup.
That design has two direct operational consequences. First, connections are expensive: each backend carries its own memory allocations and its own work_mem budget per plan node, so a few thousand idle connections can exhaust a server that comfortably handles two hundred busy ones. Second, durability and cleanup are asynchronous background activities, which means a healthy-looking instance can be silently accumulating debt in the form of unflushed dirty pages, unarchived WAL, or dead tuples nobody has reclaimed.
The configuration parameters that decide most outcomes
There is no universal PostgreSQL configuration, but there is a small set of parameters that determines whether an instance behaves predictably. MinervaDB derives these from your actual workload shape — read/write ratio, working set size, concurrency, and storage latency — rather than from a generic calculator.
| Parameter | What it governs | How MinervaDB approaches it |
|---|---|---|
| shared_buffers | Size of the shared page cache | Typically 25 percent of RAM as a starting point, then validated against buffer hit ratio and pg_stat_io read paths rather than left at the default guess |
| work_mem | Memory per sort, hash, and materialise node | Set per workload and per role, accounting for parallel workers, because the limit applies to every node in every concurrent query, not to the query as a whole |
| effective_cache_size | Planner estimate of total cache available | Tuned to reflect shared_buffers plus OS page cache so the planner stops preferring sequential scans over perfectly good indexes |
| max_wal_size / checkpoint_timeout | Checkpoint frequency and write amplification | Sized to spread checkpoint I/O smoothly instead of producing periodic latency spikes visible in application p99 metrics |
| random_page_cost | Relative cost of random I/O | Lowered on NVMe and cloud SSD estates, where the default assumption of spinning disks systematically distorts plan choice |
| autovacuum_vacuum_cost_limit | Aggressiveness of background cleanup | Raised substantially on high-churn tables, with per-table overrides so hot tables are vacuumed at the rate their write volume demands |
| max_connections | Hard ceiling on backends | Kept deliberately low and paired with PgBouncer transaction pooling instead of being raised to paper over connection sprawl |
For the authoritative parameter reference we work from the PostgreSQL server configuration documentation, and every change we propose arrives with a measured before-and-after rather than an assertion.
COMPREHENSIVE POSTGRESQL DBA SERVICES
Full-Stack PostgreSQL Support Services
Every engagement is structured so that no layer of your PostgreSQL estate is left unowned. The six practices below cover the complete lifecycle, from the first architecture review through the incident nobody expected at two in the morning.
01 / PERFORMANCE
PostgreSQL Performance Tuning
Slow queries are rarely mysterious; they are the predictable result of a decision made without measurement. We rank workload cost with pg_stat_statements, dissect plans with EXPLAIN (ANALYZE, BUFFERS), and fix the specific cause — a missing composite index, a correlated predicate the planner cannot estimate, a work_mem starved sort spilling to disk.
- Query and execution plan forensics
- Index strategy, including partial, covering, GIN, GiST and BRIN
- Partitioning design and pruning verification
- Connection pooling and concurrency control
- Extended statistics for correlated columns
- Plan regression detection after upgrades
02 / HIGH AVAILABILITY
Replication and High Availability
We design PostgreSQL clusters around the failure modes that actually occur: a zone loss, a full disk, a runaway vacuum, a network partition that leaves two nodes convinced they are primary. Quorum-based synchronous commit, fencing, and rehearsed failover replace hope with an engineered RPO and RTO.
- Streaming replication and quorum synchronous commit
- Patroni, etcd and Consul cluster management
- Logical replication and selective data distribution
- Automatic failover with fencing and split-brain prevention
- Cross-region and cross-cloud standby topologies
- Documented failover rehearsals with measured RTO
03 / REMOTE DBA
24×7 PostgreSQL Remote DBA
Enterprise-grade PostgreSQL Support without the cost and recruiting risk of building a full in-house rota. Principal DBAs monitor, patch, tune, and defend your clusters continuously, and escalate to a named engineer the moment an SLO is threatened.
- Continuous monitoring with SLO-based alerting
- 15-minute critical incident response
- Patch, minor version and extension lifecycle management
- Backup verification and restore rehearsal
- Capacity and growth modelling
- Monthly health and performance reporting
04 / MIGRATIONS
Migrations and Version Upgrades
Moving to PostgreSQL from Oracle, SQL Server, or MySQL — or moving between major PostgreSQL versions — is a rehearsal problem, not a courage problem. We test, measure, and build the rollback path first, which is why our cutovers are boring.
- Oracle, SQL Server and MySQL to PostgreSQL migration
- Major version upgrades via pg_upgrade or logical replication
- Near-zero-downtime cutover with reverse replication ready
- Extension and dialect compatibility analysis
- Cloud migration to RDS, Aurora, Cloud SQL and AlloyDB
- Post-migration tuning and cost optimisation
05 / SECURITY
Security and Compliance Hardening
PostgreSQL holds your most sensitive data, so we treat security as an engineering discipline rather than a checklist: least-privilege roles, encrypted transport and storage, auditable access, and controls mapped to the frameworks your auditors actually test.
- Role design, row-level security and column masking
- TLS enforcement, certificate authentication and SCRAM
- Transparent disk and tablespace encryption patterns
- pgAudit configuration and log pipeline integration
- CIS benchmark alignment and vulnerability review
- SOC 2, ISO 27001, HIPAA, PCI DSS and GDPR support
06 / EMERGENCY
Emergency PostgreSQL Support
When a cluster is down, a slot has filled the volume, or someone has run an unqualified DELETE in production, you need an engineer immediately. Our emergency PostgreSQL Support line connects you to a principal DBA who has resolved that failure before.
- Outage triage and service restoration
- Corruption diagnosis and page-level recovery
- Point-in-time recovery to the second before the mistake
- Transaction ID wraparound rescue
- Replication rebuild and slot recovery
- Written root cause analysis and hardening plan
REPLICATION AND HIGH AVAILABILITY
Durability, Replication Lag, and Failover That Has Been Rehearsed
Every committed transaction in PostgreSQL becomes a write-ahead log record before it becomes a changed data page. That single design decision is what makes crash recovery, streaming replication, and point-in-time recovery possible — and it is also where most durability misunderstandings begin. The level you choose for synchronous_commit decides precisely how much data you are prepared to lose.
Replication lag is three separate measurements
Teams routinely report a single lag number, which hides the problem. A standby can have received WAL it has not flushed, flushed WAL it has not replayed, or replayed everything while a long-running reporting query blocks visibility. We monitor write, flush, and replay lag independently through pg_stat_replication, alongside retained bytes in pg_replication_slots — because an abandoned slot is one of the few PostgreSQL failure modes that will take a healthy primary offline by filling its WAL volume.
Logical replication adds a second class of risk worth naming: it does not replicate DDL, sequences need explicit handling, and a subscription can fall behind indefinitely while everything looks green. Our PostgreSQL Support covers both physical and logical topologies, including the hybrid designs used for zero-downtime major version upgrades.
Failover that is tested, not assumed
An untested failover is a theory. We build clusters on Patroni with a quorum-backed configuration store, verify that fencing genuinely prevents two writable primaries, and then rehearse the failover on a schedule so the recovery time objective in your DR document is a number somebody has actually measured. The PostgreSQL high availability documentation describes the primitives; the engineering lies in the failure paths between them.
| Design decision | Conservative option | Aggressive option | What it costs you |
|---|---|---|---|
| synchronous_commit | on, with a quorum of standbys | local or off | Commit latency rises by roughly one network round trip in exchange for zero data loss |
| Standby placement | Separate availability zone or region | Same rack or same zone | Cross-zone replication adds latency but survives the failure that actually takes datacentres down |
| Failover trigger | Automated with fencing | Manual with human confirmation | Automation cuts RTO to seconds; without fencing it risks split brain |
| Replication slots | Physical slots with monitoring | No slots, rely on wal_keep_size | Slots guarantee the standby can catch up, but an orphaned slot will fill your WAL volume |
| Connection routing | HAProxy or pgBouncer health checks | DNS failover | Health-check routing follows a promotion in seconds; DNS caching can strand writes for minutes |
MVCC, BLOAT AND AUTOVACUUM
The Failure Mode That Quietly Ends PostgreSQL Deployments
PostgreSQL never updates a row in place. An UPDATE writes a new tuple version and stamps the old one with the transaction that superseded it; a DELETE only stamps the deleting transaction. The old versions remain in the heap until autovacuum proves no snapshot can still see them. This is what gives PostgreSQL its excellent concurrency — readers never block writers — and it is also the source of the single most common cause of degraded enterprise clusters: bloat.
Why autovacuum appears to stop working
Autovacuum is almost never broken. It is usually blocked or throttled. Anything holding an old transaction ID — an idle-in-transaction application session, a forgotten replication slot, an orphaned prepared transaction, or a long analytical query on a standby with hot_standby_feedback enabled — pins the xmin horizon, and nothing newer than that horizon can be reclaimed on any table in the cluster. Meanwhile the default cost limits are conservative enough that a high-churn table can generate dead tuples faster than the default worker will clean them.
Left alone, this ends in one of two places: a table whose physical size is many multiples of its live data, with index scans dragging correspondingly, or transaction ID exhaustion, where PostgreSQL forces an aggressive anti-wraparound vacuum and refuses new write transactions until it completes. Both are entirely preventable with monitoring that watches the right numbers.
| Signal to monitor | Where it comes from | Why it matters for PostgreSQL Support |
|---|---|---|
| n_dead_tup versus n_live_tup | pg_stat_user_tables | The earliest quantitative warning that cleanup is losing ground against write volume on a specific table |
| age(datfrozenxid) | pg_database | Distance to transaction ID wraparound; a rising value on a busy cluster is an incident waiting for a date |
| Oldest xact start time | pg_stat_activity | Identifies the exact session or slot pinning the xmin horizon and blocking reclamation cluster-wide |
| Retained WAL per slot | pg_replication_slots | An inactive slot silently consumes the WAL volume until the primary can no longer write |
| Index versus table size ratio | pg_class and pgstattuple | Reveals index bloat that a table-level vacuum will not resolve and that needs REINDEX CONCURRENTLY |
| Autovacuum worker saturation | pg_stat_progress_vacuum | Shows whether workers are running continuously and still falling behind, which means cost limits need raising |
Our remediation is boring by design: per-table autovacuum thresholds tuned to each table’s churn rate, cost limits raised to match your storage throughput, HOT-update-friendly fillfactor on hot tables, REINDEX CONCURRENTLY scheduled where index bloat dominates, and alerting on the xmin horizon itself rather than on its eventual symptoms.
POSTGRESQL PERFORMANCE ENGINEERING
PostgreSQL Performance Tuning Is in Our DNA
MinervaDB was founded by database performance engineers, and it shows in how we approach a slow PostgreSQL system. We do not begin with configuration changes. We begin by ranking where time is actually spent, then follow the evidence to the specific plan node, lock, or I/O path responsible.
The planner is only as good as its statistics
Most bad plans are not planner bugs; they are estimation failures. PostgreSQL costs each candidate path using per-column statistics that assume independence between predicates. When your WHERE clause filters on city and postcode, or on status and created_at, that assumption collapses and the row estimate can be wrong by orders of magnitude — which is how a nested loop gets chosen for two million rows. Extended statistics objects fix the estimate rather than forcing the plan, which is why we reach for them before hints or query rewrites.
Indexing beyond the B-tree
PostgreSQL offers far more index machinery than most estates use. Partial indexes shrink hot lookups to the rows that matter; covering indexes with INCLUDE enable index-only scans; GIN serves JSONB containment and full-text search; BRIN handles naturally ordered append-only data at a fraction of the size; and pgvector’s HNSW indexes bring approximate nearest-neighbour search to the same cluster as your transactional data. Choosing correctly between them is ordinary work for our engineers and unfamiliar territory for most application teams.
Reading wait events instead of guessing
When throughput drops, the fastest path to the cause is asking every backend what it is waiting on. Lock waits point at conflicting DDL or long transactions; LWLock waits usually mean too many connections fighting over buffer mapping; DataFileRead means the working set no longer fits in cache; ClientRead means your application is holding transactions open across network calls. Each class has a different fix, and treating them interchangeably is why so much tuning effort produces nothing measurable.
| Symptom you can see | Likely cause we look for first | Typical resolution |
|---|---|---|
| p99 latency spikes every few minutes | Checkpoint I/O bunching against a small max_wal_size | Enlarge max_wal_size, tune checkpoint_completion_target, verify with pg_stat_bgwriter |
| Query fast in staging, slow in production | Estimation error from correlated predicates or stale statistics | CREATE STATISTICS on the correlated columns, raise per-column statistics targets |
| CPU saturated with modest throughput | Sequential scans preferred because random_page_cost is unrealistic | Recost for SSD or NVMe storage and correct effective_cache_size |
| Sorts and hashes spilling to disk | work_mem too small for the plan shape and parallel degree | Right-size work_mem per role and workload rather than globally |
| Throughput collapses as users grow | Thousands of backends contending in shared memory | Introduce PgBouncer transaction pooling and lower max_connections |
| One tenant degrades everything | No workload isolation between OLTP and reporting | Route analytics to a standby, add statement timeouts and per-role limits |
For deeper technical background our team publishes continuously on PostgreSQL consulting engagements and shares the diagnostic queries we use in production on the MinervaDB engineering blog.
BACKUP, PITR AND DISASTER RECOVERY
A Backup You Have Never Restored Is Only a Hypothesis
PostgreSQL point-in-time recovery works by combining a physical base backup with the unbroken chain of WAL segments that follows it. Restore the base, replay WAL to a chosen instant, and you have the cluster exactly as it stood one second before the bad migration ran. The mechanism is reliable; what fails in practice is the operational discipline around it — an archive command that silently started failing, a retention policy that expired the WAL you needed, or a recovery nobody had ever timed.
What we verify, continuously
Our PostgreSQL Support treats recoverability as a measured property of the estate. Archive success is monitored as a first-class metric, not inferred from the absence of complaints. Retention is calculated backwards from your stated recovery window. Restores are rehearsed automatically into an isolated environment, page checksums are verified, and the elapsed time is recorded so your documented RTO reflects reality rather than optimism. When logical corruption is the risk rather than hardware loss, we pair PITR with delayed standbys so there is a warm cluster sitting deliberately in the past.
| Recovery scenario | Mechanism we rely on | Realistic expectation |
|---|---|---|
| Single table dropped by mistake | PITR into a clone, then logical export of the table | Minutes to a clone; no impact on the production cluster |
| Whole cluster lost with the host | Base backup plus WAL replay from object storage | RTO driven by restore bandwidth and WAL volume, typically under an hour for multi-terabyte estates |
| Logical corruption discovered hours later | Delayed standby or PITR to a chosen timestamp | Recovery to seconds before the damaging statement, provided the WAL chain is intact |
| Availability zone failure | Automated failover to a standby in another zone | Seconds of RTO with zero RPO under quorum synchronous commit |
| Region-wide outage | Cross-region standby with independent archive | Minutes of RTO, with RPO bounded by cross-region replication lag |
| Ransomware or credential compromise | Immutable object-lock archive plus offline copy | Recovery independent of any credential that was compromised |
MONITORING AND OBSERVABILITY
Instrumentation That Predicts Incidents Instead of Narrating Them
Most PostgreSQL monitoring reports that something has already gone wrong. Useful monitoring shows the trend that will cause the next outage, which means alerting on saturation and horizon metrics rather than on CPU and disk alone. We instrument every cluster with the same discipline whether it runs on your hardware, in Kubernetes, or on a managed cloud service.
| Metric | Source | Alert philosophy |
|---|---|---|
| Replication write, flush and replay lag | pg_stat_replication | Alert against the SLO you promised the business, separately for each lag component |
| Retained WAL per replication slot | pg_replication_slots | Page before the volume fills, not when writes have already stopped |
| Transaction ID age | pg_database and pg_class | Warn at a comfortable fraction of autovacuum_freeze_max_age so intervention is routine |
| Dead tuple ratio per table | pg_stat_user_tables | Track per table; a cluster average hides the one table that matters |
| Checkpoint timing and buffers written | pg_stat_bgwriter | Detect checkpoint bunching before users feel latency spikes |
| Wait event distribution | pg_stat_activity sampling | Continuous sampling turns after-the-fact guesswork into evidence |
| Cache hit ratio and read paths | pg_stat_io and pg_statio_user_tables | Distinguish a genuine memory shortfall from a bad index choice |
| Connection saturation | pg_stat_activity and pooler stats | Alert on pool exhaustion, which arrives long before max_connections does |
We deploy this with tooling you can keep and operate yourself — Prometheus exporters, Grafana dashboards, pgwatch2, or your existing observability platform — and we hand over the alert definitions with the rationale for each threshold documented.
SECURITY AND COMPLIANCE
PostgreSQL Security Engineered for Audit, Not for Appearance
PostgreSQL provides genuinely strong security primitives, and enterprises routinely leave most of them unused. The default state of many production clusters is broad role membership, trust or password authentication in place of SCRAM, unlogged privileged access, and superuser credentials embedded in application configuration. Our hardening work replaces that with a least-privilege model your auditors can verify.
The controls we implement
Role hierarchies that separate schema ownership from application access; SCRAM-SHA-256 or certificate authentication with TLS enforced at the server; row-level security policies for multi-tenant schemas; column-level masking through views for sensitive attributes; pgAudit configured for privileged statement and object access, shipped to a log pipeline outside the database host; encryption at rest via filesystem or volume encryption with managed keys; and network isolation that stops treating a database port as an internal detail.
We map these controls to SOC 2, ISO 27001, HIPAA, PCI DSS and GDPR requirements, align configuration to the CIS PostgreSQL Benchmark, and produce the evidence pack your auditors ask for. Where a regulator requires demonstrable separation of duties, we operate under that model rather than around it.
For teams running PostgreSQL in containers, our PostgreSQL on Kubernetes engineering practice extends the same controls to operators, secrets management, and storage classes.
VERSIONS AND PLATFORMS
PostgreSQL Support Across Every Version and Deployment Model
We support PostgreSQL wherever it runs, and we support the parts of the ecosystem your applications actually depend on. That includes the extensions that make PostgreSQL viable for geospatial, time-series, and AI workloads, and the managed services whose abstractions change which levers remain available to you.
Asynchronous I/O, improved vacuum efficiency and planner refinements
Incremental base backups, improved vacuum memory management
Logical replication from standbys, MERGE, parallel improvements
Supported for operations and upgrade planning to current releases
PostgreSQL 12 and earlier: risk assessment and rehearsed upgrade
Parameter groups, IAM, storage autoscaling and cost tuning
Read pools, columnar acceleration and migration engineering
Flexible Server HA, zone redundancy and burst behaviour
CloudNativePG, Zalando, Crunchy and Patroni-based topologies
pgvector, PostGIS, TimescaleDB, pg_partman, pg_stat_statements, pgAudit
Distributed tables, colocation strategy and rebalancing
NVMe tuning, NUMA alignment, filesystem and kernel parameters
UPGRADES AND MIGRATIONS
Major Version Upgrades Without the Weekend Outage
PostgreSQL releases a major version every year and supports each for five. Falling behind is a slow accumulation of risk: unpatched vulnerabilities, planner improvements you are paying for in latency, and eventually an upgrade so large that nobody wants to schedule it. We treat upgrades as routine, rehearsed operations.
Choosing the right cutover mechanism
For most clusters, pg_upgrade in link mode converts a multi-terabyte instance in minutes rather than hours, and the rehearsal on a clone tells us exactly how many minutes. Where even that window is unacceptable, we use logical replication to build the new version alongside the old, let it catch up, verify row counts and checksums, and cut over with reverse replication configured so that rolling back is a routing change rather than a restore. The official PostgreSQL upgrade documentation covers the mechanics; the risk lives in extension compatibility, collation changes that can silently corrupt index ordering, and the plan regressions that appear only under production concurrency.
Migrations from other engines follow the same discipline. Oracle PL/SQL, SQL Server T-SQL, and MySQL dialect differences are catalogued before anyone writes conversion code, data types with no clean analogue are decided deliberately rather than by tool default, and the new PostgreSQL schema is designed for PostgreSQL rather than transliterated from its predecessor. Teams already running SQL Server support alongside PostgreSQL frequently consolidate both under one MinervaDB engagement.
HOW WE ENGAGE
PostgreSQL Support Engagement Models
Whether you need continuous managed coverage, a single deep assessment, an engineer on the phone during an active incident, or embedded expertise for a major programme, there is an engagement model that fits without forcing you into a retainer you do not need.
| Engagement model | Best for | What you get |
|---|---|---|
| 24×7 Managed PostgreSQL DBA | Teams needing round-the-clock coverage without building an in-house rota | SLO-backed monitoring, 15-minute critical response, continuous tuning, monthly reporting |
| PostgreSQL Performance Audit | Slow clusters, rising cloud spend, recurring incidents | Evidence-based findings, prioritised remediation plan, tuned configuration and indexes |
| Emergency PostgreSQL Support | Active outages, corruption, wraparound, broken replication | Immediate principal-level engagement, restoration, written root cause analysis |
| HA and DR Engineering | Clusters that need a real RPO and RTO | Cluster design, Patroni deployment, rehearsed failover, DR runbooks |
| Migration and Upgrade Programme | Engine migration or major version upgrade | Assessment, rehearsal, cutover execution, tested rollback path, post-migration tuning |
| Embedded PostgreSQL Engineering | Build-outs, modernisation, scale initiatives | Senior engineers integrated with your team, roadmap and code review included |
24×7 OPERATIONS
What Happens When Your PostgreSQL Cluster Pages Us at 3 A.M.
Support quality is decided in the first ten minutes of an incident. Our model removes the two things that waste those minutes: tiered queues that route you through people who cannot help, and a handover to an engineer who has never seen your estate. Every severity-one incident reaches a principal PostgreSQL engineer who already knows your topology.
Mitigation is never the end of the engagement. Within forty-eight hours you receive a written root cause analysis with the evidence attached — the plans, the wait events, the log excerpts — and a hardening change that prevents recurrence goes into the next maintenance window. Incidents we resolve twice are incidents we have failed to fix once.
INDUSTRIES WE SERVE
PostgreSQL Support for the Most Demanding Workloads
PostgreSQL now sits under workloads that once belonged exclusively to proprietary engines. Each industry brings a different definition of unacceptable failure, and our engagements are shaped around that definition rather than a generic service catalogue.
Ledgers, payment rails and regulatory reporting where ACID semantics are non-negotiable and every millisecond of commit latency is measured, audited and defended.
HIPAA-aligned clusters behind clinical systems and research platforms, where data integrity is a patient safety property rather than an operational metric.
Multi-tenant PostgreSQL schemas with row-level security, per-tenant isolation strategies, and scale paths that survive a customer ten times larger than your current biggest.
Order, inventory and catalogue systems engineered to absorb peak-season traffic without lock contention, replication lag, or oversold stock.
pgvector estates serving embedding search alongside transactional data, tuned for recall, index build time, and the memory profile HNSW actually needs.
Sovereignty-aware deployments with strict auditability, documented change control, and support models that satisfy procurement as well as engineering.
The best PostgreSQL Support is the kind your users never notice. Our job is to make replication boring, recovery rehearsed, and query latency predictable enough that the database stops being a topic of conversation.
— THE MINERVADB POSTGRESQL ENGINEERING TEAM
FAQ
Frequently Asked Questions About PostgreSQL Support
What does MinervaDB PostgreSQL Support include?
Our PostgreSQL Support covers the full lifecycle of your estate: architecture and capacity design, query and index tuning, streaming and logical replication, high availability with automatic failover, backup and point-in-time recovery verification, security hardening, major version upgrades, and 24×7 incident response. Engagements are delivered by principal-level PostgreSQL DBAs and measured against written service level objectives.
How fast do you respond to a critical PostgreSQL incident?
Severity-one incidents — an outage, corruption, a failed failover, or broken replication — carry a 15-minute response SLA, and our follow-the-sun rota means a senior PostgreSQL engineer is on call in every time zone. You reach that engineer directly. There is no first-line queue and no script.
Can you support PostgreSQL on Amazon RDS, Aurora, Cloud SQL or Azure?
Yes. We support self-managed PostgreSQL on bare metal and virtual machines, PostgreSQL on Kubernetes through operators such as CloudNativePG and Patroni, and managed services including Amazon RDS and Aurora, Google Cloud SQL and AlloyDB, and Azure Database for PostgreSQL. Managed platforms remove some levers and add others, and our tuning work reflects what each platform actually exposes.
Which PostgreSQL versions do you support?
We support all community-supported major versions, currently PostgreSQL 13 through 18, and we continue to operate older releases while planning a rehearsed upgrade path. For end-of-life versions we quantify the risk, catalogue extension and collation compatibility, and execute the upgrade with a tested rollback plan.
How do you diagnose a PostgreSQL performance problem?
We rank workload cost with pg_stat_statements, capture real plans with EXPLAIN (ANALYZE, BUFFERS) and auto_explain, sample wait events from pg_stat_activity, and examine read paths through pg_stat_io. That evidence identifies whether the cause is an estimation error, a missing or wrong index, insufficient work_mem, lock contention, or checkpoint I/O — and each has a different fix. Every recommendation is validated by measurement before and after the change.
Do you replace our internal DBA team?
Either model works. Many clients keep their internal team and use MinervaDB for depth they cannot justify hiring for — replication design, upgrade rehearsals, performance forensics, and out-of-hours cover. Others hand us the whole PostgreSQL DBA function. In both cases we document everything and train your engineers as we work.
How do you prevent table bloat and transaction ID wraparound?
We monitor dead tuple ratios per table, the age of the oldest transaction, transaction ID age against autovacuum_freeze_max_age, and retained WAL per replication slot. Remediation means per-table autovacuum thresholds matched to churn, cost limits raised to match storage throughput, fillfactor tuned to encourage HOT updates, REINDEX CONCURRENTLY where index bloat dominates, and alerting on the xmin horizon rather than on its eventual symptoms.
What availability can PostgreSQL realistically achieve?
With quorum synchronous commit across availability zones, Patroni-managed automatic failover with fencing, health-check-based connection routing, and rehearsed runbooks, we routinely engineer clusters to a measured recovery time of twenty to forty seconds with zero data loss. The constraint is almost never PostgreSQL itself; it is whether the surrounding automation, routing, and rehearsal discipline exist.
RELATED SERVICES
Explore Related MinervaDB Services
GET POSTGRESQL SUPPORT TODAY
Let Us Engineer a PostgreSQL Estate You Never Have to Worry About
Talk to a MinervaDB principal PostgreSQL engineer about the cluster that is keeping you awake. The first conversation is always with an engineer, never a salesperson — no obligation, no generic pitch, just an expert read on your specific situation.