PrepBusiness: Eliminating Database Outages While Doubling Hardware Capacity

PrepBusiness (part of the Jasara group) is a Canadian SaaS company that provides warehouse management and logistics software for Amazon FBA prep centres around the world.

They were running on AWS with a mix of ECS, EKS, and RDS, and recurring 1 to 2 minute outages kept hitting customer-facing services without a clear cause. Their RDS instance was under-resourced, external contractors were handling their AWS maintenance, and the team did not have the observability tooling needed to see what was happening inside the database when requests timed out.

Dedicated bare-metal Kubernetes cluster

We deployed a multi-node bare-metal cluster in Germany running our full managed Kubernetes stack: RKE2, Cilium with WireGuard encryption and BGP routing, AES-256-GCM encrypted OpenEBS ZFS storage, and replicated Mayastor NVMe-oF volumes. The new cluster more than doubled their available compute and memory at the same monthly cost they were paying AWS.

15-minute database cutover from AWS RDS

We established a private network link between their AWS VPC and our cluster and configured live logical replication from AWS RDS into a high-availability PostgreSQL cluster managed by StackGres. PrepBusiness chose a weekend maintenance window for the final switchover, which completed in 15 minutes. The entire migration from contract signing to production go-live took 45 days.

Isolating the recurring 2-minute database lockups

The sporadic 1 to 2 minute freezes persisted after the migration, which showed us that the underlying AWS hardware was not the root cause. While we investigated, we used the spare capacity on the new bare-metal nodes to double the database’s CPU and memory allocation at no extra cost.

We used our observability stack (Prometheus metrics, Loki logging rules, and custom Grafana dashboards) to instrument the PostgreSQL layer over several weeks. The metrics showed that long-running application queries, PostgreSQL autovacuum, and scheduled business maintenance jobs were all running on the database at the same time. CPU usage stayed at around 20 cores during those windows, saturating the database so that customer web requests queued up and timed out after 30 seconds. Once we could see the overlapping loads in Grafana, we rescheduled the maintenance jobs and tuned the query patterns so they no longer competed with live traffic, which ended the outages.

“We were struggling to pin down an issue that would cause unpredictable downtime for all our customers. Lithus dug into it with us, built dashboards to help us observe performance across all our services, and ultimately isolated the issue so that we could push out a fix.”

Keith Brink, Founder, PrepBusiness

In 2026, Jasara was also running a high-throughput label-generation service (AZLabels, rendering hundreds of shipping labels per minute) on a separate DigitalOcean Managed Kubernetes (DOKS) cluster backed by DigitalOcean Managed PostgreSQL and Valkey. A DigitalOcean network blip severed their in-cluster NFS provisioner and caused a 12-hour outage where every web and queue pod hung in uninterruptible sleep while Kubernetes health checks still reported the pods as healthy.

Because their Lithus bare-metal cluster already had ample headroom, we worked with their engineers to move AZLabels onto the existing cluster at no additional cost. Together we removed the fragile shared NFS mount by moving cross-process handoffs to object storage, job status tracking to PostgreSQL, and render scratch files to fast pod-local NVMe storage (which also prevented a race condition where two workers could occasionally process the same render job twice). We added Redis Sentinel support to their Laravel application, verified and restored all 4.9 million rows of their PostgreSQL database onto StackGres, and cut DNS over to the Lithus cluster, retiring their DigitalOcean Kubernetes cluster and managed databases completely.

Alongside their production applications, we also run KubeVirt virtual machines on the cluster to host dedicated GitHub Actions CI/CD runners, and we have upgraded their PHP application runtime from the deprecated NGINX Unit server to FrankenPHP as part of their included engineering time.