- Industry: Clinical-trial medical imaging (life sciences technology)
- Organization: A clinical-trial imaging network provider whose platform moves trial images between hospitals and sponsors
- Environment: Self-managed PostgreSQL and AWS RDS across the engagement; currently PostgreSQL 17 in production
- Engagement: PostgreSQL support and consulting, ongoing since April 2008 (18 years, 134 tickets)
- Services: Major-version upgrades · Performance engineering · High availability & PITR · Emergency incident response
| Metric | Before | After |
|---|---|---|
| Slowest client-facing QC report | 9+ minutes on PostgreSQL 13 | ~30 seconds on PostgreSQL 17 after our rewrite (18x) |
| Payment report | ~4 minutes on PostgreSQL 13 | ~1.5 minutes on PostgreSQL 17 |
| PostgreSQL major version | 13 | 17, live in production February 2026 |
Contact us
Reach out! This is your best opportunity to build a partnership with a leader in Postgres and Open Source support.
The Client
The client runs a clinical-trial imaging network. When a hospital scans a trial patient, the platform carries that image to the trial sponsor, with the chain of custody a regulated study demands. PostgreSQL sits under all of it: the submissions, the audit trail, the reports sponsors read. A slow database is a slow trial. They have been our client since April 2008.
The Challenge
The challenge changed every few years, which is the point of this story. In 2008 it was autovacuum failing to keep up on PostgreSQL 8.1. In the early 2010s it was uptime: the platform needed real high availability and point-in-time recovery, not a single box and a prayer. In 2013 it was a production-down emergency, submissions failing with a numeric-overflow error nobody could explain. In 2021 it was a cloud upgrade gone wrong: an RDS jump from 9.6 to 13, performed without us, left the production database nearly unusable. And in 2026 it was speed at the finish line of a 13-to-17 upgrade: the company set a goal that every custom client report return in under one minute, and the worst one took more than nine.
The Solution
We solved each era's problem as it arrived.
- Foundation and forensics. We tuned vacuum and maintenance and pushed the upgrade path forward. When a high-churn table kept growing despite aggressive vacuuming, we traced the free-space accounting instead of guessing.
- High availability. We built their DRBD and corosync failover stack, reconfigured it as the platform grew to multiple PostgreSQL instances, and put point-in-time recovery underneath it.
- The 2013 emergency. Image submissions were failing with "numeric value out of range". We traced it the same day: large-object IDs are unsigned 32-bit values, and a signed 32-bit cast in the application stack turned any ID past 2.1 billion into garbage.
- Security design. Over several years we designed and tuned the row-level-security policies that keep one sponsor's trial data invisible to another, including the complex-join policies and the performance work to make them affordable.
The Results
The QC report went from 9+ minutes to roughly 30 seconds, an 18x improvement, and the payment report from 4 minutes to 1.5. PostgreSQL 17 went live in production in February 2026 with our engineers on the tickets before and after cutover. Eleven emergencies over the years, all resolved. And a platform that started on PostgreSQL 8.1 is now on 17 without ever losing its database along the way.
Why it Matters
Nobody at Command Prompt had to be told what this database does, how the imaging workflow behaves under load, or why the row-level-security policies look the way they do. We wrote that history, and we were still here to use it. Eighteen years is not a vendor relationship, it is a partnership.