How Dispatch speeds up development with Neon while keeping workloads on Aurora
They use Neon branches for their ephemeral environments
“Neon’s branching paradigm has been great for us. It lets us create isolated environments without having to move huge amounts of data around. This has lightened the load on our ops team, now it’s effortless to spin up entire environments.”
Jonathan Reyes, Principal Engineer at Dispatch
Dispatch is a technology company that simplifies last-mile delivery for businesses by streamlining the process of tracking deliveries, coordinating drivers, and communicating with customers. The Dispatch platform solves the tricky challenge of efficiently managing the final stage of delivery in many different locations at once, which is usually the most complex and expensive piece of the puzzle for large enterprises.
Founded in 2016, Dispatch operates in over 75 U.S. markets, providing on-demand delivery solutions via its network of independent contractor drivers and courier partners.
Adopting serverless to alleviate overprovisioning and accelerate development
Dispatch runs its database infrastructure on AWS Aurora Global. While Aurora offers multi-region availability and handles traffic relatively well, it’s not the most cost-efficient solution to handle their spiky traffic patterns.
During peak hours in the morning, when most orders come in, Dispatch had to overprovision Aurora by 10x their average usage. This overprovisioning was necessary because Aurora only includes a single writer, and the writer database would often become the single point of failure.
“We had to overprovision Aurora to handle our spiky traffic, and even then, the writer database would get overwhelmed. We provision 10x more than we need on average to keep things running smoothly”
Jonathan Reyes, Principal Engineer at Dispatch
Dispatch is looking to Neon’s serverless writer endpoints to help alleviate this pain point. At the same time, they’re accelerating their SDLC workflow while reducing cots by using Neon branches to create their development environments.
How Dispatch uses Neon for their ephemeral environments
The Dispatch team is transitioning from a monolithic to a microservices architecture. As part of this transition, they wanted to create a more agile workflow that would allow them to replicate a portion of their workload data (excluding PII) for testing in ephemeral environments.
“Getting realistic data into our verification environments was largely unfeasible, it was time-consuming, expensive, and a beast to maintain. You need to process hefty backups, transfer costs stack up, and there’s a lot of manual oversight required just to move that data”
Jonathan Reyes, Principal Engineer at Dispatch
To improve their development experience, Dispatch started using Neon as their ephemeral environment database. They didn’t immediately migrate workloads off Aurora—a huge undertaking—but began experimenting with Neon as a more agile solution for their various workloads.
Here’s a summary of how their deployment looks now:
Scheduled syncing of environments via AWS DMS
The Dispatch team synchronizes their development environments with a safe, SOC 2-compliant subset of various workloads on a scheduled basis. To do this, they use AWS Database Migration Service (DMS) to replicate data from their Aurora cluster into a main branch in Neon.
This scheduled sync gives them an up-to-date snapshot of their data, which is then used for testing and development. As they move toward more advanced workflows, they are considering transitioning to streaming replication to enable real-time data syncing, especially for scenarios like shadow environments.
Neon branches for each environment
Neon’s branching model allows Dispatch to create isolated environments for testing without having to manually “copy” large datasets into new instances. Developers or QA team members can quickly spin up a new environment by running a simple command with their internal tooling. This environment includes a safe, sanitized, subset of data and is available immediately.
These branches are isolated—any changes or destructive tests are confined to the branch. For instance, feature teams that need access to real-world data for A/B testing or debugging can easily create a branch and conduct tests without worrying about affecting any other environments.
Managing branches via Kubernetes
Dispatch has integrated Neon’s branching into their Kubernetes infrastructure. They’ve built a custom Neon operator for Kubernetes that automatically creates branches whenever a new ephemeral environment is spun up.
These ephemeral environments are a key part of Dispatch’s development process. They can quickly spin up entire stacks for testing, which include isolated instances of Neon’s databases. This isolation allows them to perform resource-heavy operations without putting additional load on other critical workloads.
Neon’s read replicas for ETL and analytics
In addition to their primary workflow, Dispatch uses Neon’s read replicas (read-only endpoints) to make their data pipelines more efficient. Previously, they ran both critical workloads and ETL jobs on the readers of their Aurora Global cluster, which caused frequent issues. Now, they create read-only replicas in Neon for specific use cases. For example, team members who need reports can run live data queries in tools like Metabase without having to wait for ETL pipelines to finish.
If you’re running Postgres in AWS, give Neon a try
It may not be the right time to move your workload off your current database, but you can still benefit from Neon’s DX for your dev/test environments. If you haven’t used Neon before, start by creating a free account and spin up a few branches. You can also explore our resources on using Neon for dev to help you get started.
A big thank you to Dispatch for sharing their story! Check out their resources to learn more about the company and their delivery tech.
Continue reading about how to use Neon for your dev/test environments:
