About PGFlare — Managed AWS PostgreSQL RDS Performance Engineering

Our Mission

Make expert PostgreSQL performance engineering accessible to every engineering team

The engineers who can genuinely diagnose, remediate, and continuously improve a complex AWS PostgreSQL RDS deployment are rare. Most organisations either can’t afford them full-time or can’t justify the headcount for a problem that feels reactive.

PGFlare makes performance expertise available as a managed service — continuous monitoring that never sleeps, advisory reports that tell you exactly what to fix, and active remediation that applies the fixes safely and without downtime.

Your engineers get to focus on building product. Your database gets faster. Your AWS bill goes down.

40ms

Median query improvement for customers in their first 30 days

23%

Average reduction in RDS instance cost after 90 days

48h

From onboarding to first actionable advisory report

Downtime events caused by a PGFlare-applied change

Our Story

How PGFlare came to exist

PGFlare was founded by engineers who spent years embedded in platform and infrastructure teams at high-growth SaaS companies and regulated financial services businesses. Time and again we watched the same pattern repeat: a product team would hit a database performance wall, the instinct would be to scale RDS vertically, the AWS bill would grow, and the underlying query problem would remain completely unaddressed.

We watched organisations pay £15,000–£40,000 per month in AWS RDS costs for databases that were fundamentally misconfigured. We watched platform engineers get paged at 2am for connection pool exhaustion events that could have been prevented with a ten-line autovacuum configuration change. We watched compliance teams scramble to explain database incidents to auditors with no change log to point to.

The tooling existed to fix these problems. pg_stat_statements, pg_stat_bgwriter, pg_locks — all the data needed to diagnose and remediate performance issues is right there in PostgreSQL. What organisations lacked wasn’t data. It was the expertise to interpret it and the dedicated time to act on it.

PGFlare was built to fill that gap. We connect to your AWS RDS instance via a read-only IAM role, ingest the performance data PostgreSQL already generates, run it through our analysis models, and tell you — in plain English — exactly what to fix and why it matters. On Remediation+ sessions, we apply the fixes ourselves, safely, without touching your application data and without requiring downtime.

Why PostgreSQL 16.9 Specifically

The 16.x upgrade changed things. Most teams haven’t adapted.

AWS RDS PostgreSQL 16.x introduced significant changes to the query planner, parallel query execution, and statistics collection. Workloads that performed predictably on 15.x are exhibiting regression patterns on 16.9 — and the standard monitoring tools don’t surface why.

Query Planner Changes

Planner cost model revisions

PostgreSQL 16 revised the default cost models for sequential scans, parallel workers, and index usage thresholds. Queries that used preferred index paths on 15.x may now plan differently — often worse — without any change to your application code.

Statistics Behaviour

Extended statistics scope

16.x extended the reach of CREATE STATISTICS for multi-column correlation, but the default statistics targets in AWS RDS don’t take advantage of this. PGFlare identifies where targeted ANALYZE and statistics target changes would dramatically improve plan quality.

Parallel Query

Parallel worker behaviour changes

Changes to max_parallel_workers_per_gather and the conditions under which the planner chooses parallel execution mean that aggregate-heavy analytical queries may regress or improve unpredictably. PGFlare models these transitions and advises on parameter tuning accordingly.

How We Work

Principles that don’t change under pressure

How we operate matters as much as what we build. These are the commitments we make to every customer.

🔒

Read-only, always

Our IAM access is scoped exclusively to performance statistics views. We cannot touch application data. This is an architectural constraint, not a policy — it cannot be overridden by accident or by instruction.

📋

Nothing applied without approval

Every remediation action on Remediation+ sessions is proposed in writing before execution, with a rollback plan. We do not apply changes without your explicit written sign-off. Ever.

🌐

No vendor lock-in

Every recommendation we make is documented in plain SQL and plain English. If you choose to terminate your subscription, you keep all previous advisory reports, applied changes, and audit logs. You are never dependent on us to maintain an opaque system.

🛡

GDPR by design, not by policy

We designed PGFlare to process the minimum possible data to deliver the service. We operate UK data residency by default, maintain a GDPR-compliant data processing agreement for every customer, and never use your performance data for any purpose other than delivering the service.

🔎

Honest about what we can and can’t do

Performance engineering is not magic. Some problems require application-level refactoring that is outside PGFlare’s scope. When that’s the case, we tell you clearly and explain exactly what the application change needs to look like.

🎉

Results you can measure

Every advisory report includes estimated impact metrics. Every applied change is benchmarked before and after. Our satisfaction guarantee is not a marketing gesture — it’s a commitment that we surface measurable improvements or your Diagnostic session is repeated free of charge.

We exist because the problem is real and almost nobody is solving it properly.