Customer Story
How Digital Pioneer Autotrader UK Became a Platform Engineering Leader with Google Cloud Postgres and pganalyze

Autotrader UK, began as a print classifieds magazine but was an early web adopter in the 1990s, and, by the early 2000s, became one of the UK’s first major media brands to fully embrace digital. About a decade ago, they migrated their relational database infrastructure from Oracle Server on premise to Google Cloud, setting the foundation for a cloud-native approach to service delivery. Today, it operates as a software-first business, serving millions of customers, thousands of dealer partners, and hundreds of internal developers building cloud-native services.

Autotrader UK website.

At the heart of the company’s most recent digital evolution is a sophisticated internal app delivery platform. It allows product engineers to own their services end-to-end: from the app code, infrastructure it runs on, and any datastore that it needs. This internal platform streamlines provisioning, automates deployments, and provides a consistent set of tools to each engineer running a dedicated production-grade Postgres database on Google Cloud.

Rather than rely on a centralized DBA team with tickets piling up, the platform enables developers to answer their own performance questions, guided by shared tools and context. Today, the platform team manages roughly 160 production & 240 non-production PostgreSQL instances across Google Cloud, supporting 300+ developers who own around 750 operational services. The challenge isn't just uptime, it's enabling consistent performance and safe iteration at scale, without adding bottlenecks or centralized gatekeeping.

But with this autonomy came risk. When every team can define its server or instance and ship changes independently, how do you prevent regressions? How do you know when Postgres performance is drifting? And how do you ensure autovacuum, bloat, and query plan performance don’t degrade quietly over time?

Enabling developer velocity without losing control

The delivery platform empowered developers, but the platform team knew they needed to invest in tooling to prevent database performance issues. Since teams owned their databases and schemas, they were shipping changes regularly, including index refactors and introducing new queries. The team evaluated other database performance offerings, but ultimately felt the options were limited and made the incorrect assumption that every developer knew how to investigate degraded performance.

pganalyze table statistics for mot_test showing large deletions causing a high dead row count.

Integrating pganalyze into the delivery platform workflow

Autotrader UK adopted pganalyze to solve this exact problem: making Postgres internals observable across all services, without requiring elevated access or custom dashboards.

Lessons learned and future plans

Within days, they confirmed that insufficient VACUUM activity was happening on the mot_defect table. Due to default autovacuum_vacuum_scale_factor settings, the modified row count never exceeded the threshold, so autovacuum never ran, even though millions of rows were added each week.

pganalyze Schema Statistics view showing large table footprint of mot_test and related datasets.

pganalyze was integrated into the app delivery platform as a default dependency, meaning every new Postgres-backed service automatically came with built-in performance monitoring, query insights, and autovacuum tracking. Every schema change starts as a Git commit, then reviewed, tested, and deployed through the same platform pipelines that handle service logic. This GitOps model ensures consistency and auditability across hundreds of Postgres instances.

After identifying the vacuum scheduling issue, the team adjusted the autovacuum_vacuum_scale_factor settings to lower thresholds for large append-only tables like mot_defect. This ensured vacuum ran predictably after each import cycle. Since implementing these changes, they’ve seen sustained performance improvements and more consistent import durations without needing manual intervention or escalations.

In the early stages of solving this problem, the team experimented with running imports into empty tables to isolate the issue. Performance started off reasonably but deteriorated quickly and by early afternoon on the first day, queries had become drastically slower. Using pganalyze, developers compared EXPLAIN plans from two different trials and spotted both query plan instability and rising table size as the root

EXPLAIN plan history showing evolving query performance for mot_defect merges, with visible runtime and I/O changes over time in pganalyze.

By analyzing slowest queries and refactoring their schema, removing redundant constraints, and inlining one table within another using an array data type, the team was able to bring the import time down to under 24 hours.

Query performance trends from an Autotrader UK production database shown in pganalyze.

This not only made the import process reliable and predictable, it also reinforced that with the right insights, even seemingly complicated Postgres performance issues could be solved while maintaining the same amount of resources assigned to the database server.

A platform that enables safe autonomy

With pganalyze embedded into the platform experience, developers can now ship changes confidently and catch performance issues before they impact customers. Instead of relying on centralized DBAs, teams can:

• Track query performance after deploys
• Visualize dead tuple growth and vacuum history
• Understand the impact of schema or index changes
• Validate plans when Postgres behaves unexpectedly

Query performance trends from an Autotrader UK production database shown in pganalyze.

Even with hundreds of live Postgres databases in production, the platform team remains small. Thanks to pganalyze and the delivery platform, they can support a growing engineering org without scaling their team linearly.

The key to making this work is giving developers just enough visibility and guidance to feel confident, without overwhelming them with internals. The delivery platform handles orchestration, but it’s pganalyze that translates Postgres behavior into actionable insights. It turns what used to be black box performance mysteries into something teams can understand and improve on their own.

This mindset is core to Autotrader UK’s platform approach: enable engineers to move quickly, but safely. Rather than rely on a specialist bottleneck, the system and tooling provide smart defaults and enough context to allow for smart decisions. It’s not just autonomy. It’s supported, observable autonomy that scales with the team.

Looking ahead: scaling the platform and data layer

As Autotrader UK expands its platform footprint, the team is exploring advanced PostgreSQL features like partitioning and parallelism for large tables, as well as deeper CI integration. The goal is to catch issues during reviews or deploys, not after things break.

pganalyze remains a key layer in this platform: surfacing risk, validating improvements, and enabling teams to scale Postgres workloads safely and independently.

The team is integrating pganalyze into their continuous integration (CI) environments so that query performance and vacuum behavior can be monitored from the earliest stages of testing, not just in production. This makes it easier to catch regressions or inefficiencies before code reaches users. Developers also consult pganalyze proactively during design and review cycles, using real execution plans to validate their assumptions about schema and query behavior.

Autotrader UK’s platform journey shows what’s possible when developer autonomy is supported by strong tooling. With pganalyze in place, the team isn’t just keeping Postgres fast and reliable, they are enabling every engineer to take ownership of database performance as part of building reliable software.