Invenco runs a serverless architecture on AWS. They use Neon’s connection pooler based on pgBouncer to manage the spiky traffic generated by hundreds of Lambdas—something Aurora Serverless v2 struggled with. By migrating to Neon, Invenco reduced database costs by 80%, improved performance, and ensured smooth operations during high-traffic events.

Invenco is a logistics SaaS company that helps e-commerce businesses with fast, accurate order fulfillment and real-time tracking. They integrate with major e-commerce platforms, enabling businesses to focus on growth while Invenco manages inventory and shipping.

Aurora Serverless is… Not so serverless  

Invenco runs a serverless architecture with AWS Lambda at the core, designed to handle the spiky traffic typical from e-commerce. Given their serverless infrastructure, they needed a database that could seamlessly scale with traffic. Aurora Serverless v2 seemed like the right fit.

But surprisingly, Aurora presented technical challenges even with the most basic “serverless” tasks. Particularly, Aurora was frequently overwhelmed by the concurrent connections from AWS Lambda functions during traffic spikes. This caused dropped or refused connections. Implementing RDS Proxy, their standard solution for scaling connections, didn’t resolve the issue.

Finding Neon

“Neon worked out of the box, handling hundreds of Lambdas without any of the connection issues we saw in Aurora Serverless v2. On top of that, Neon costs us 1/6 of what we were paying with AWS” (Cody Jenkins, Head of Engineering at Invenco)

When Aurora’s issues became unmanageable, Invenco tried Neon. The benefits:

1. Improved performance. Neon’s pooled connection management worked out of the box, handling hundreds of concurrent requests without Aurora’s bottlenecks. 
2. Cheaper cost.  Invenco’s bill with Neon is approximately 1/6 of what they paid with Aurora.
3. Smoother non-prod workflows. With Neon’s branching, Invenco only loads testing data once into their staging branch. Ephemeral environments can then be instantly derived with data already included—vs having to load data into multiple environments. More on this below.

Their Neon setup

“When we moved to Neon, we consolidated all our non-prod services into a single Neon project. We just load our synthetic dataset once into the main staging branch and spin off child branches as needed. With Aurora, the process was more complex. We had to duplicate databases per service, which meant loading data separately for each environment”  (Cody Jenkins, Head of Engineering at Invenco)

Invenco’s architecture is microservices-based, with eight distinct services corresponding to different business domains such as sales, inventory, and fulfillment. Each service runs in both production and non-production environments. In Aurora, this meant a bunch of instances—in Neon, the setup looks like this: 

Each production service has its own Neon project. 

For production, Invenco follows a one-project-per-service model to isolate resources. This way each service has its own dedicated database and scaling configuration, ensuring that spikes in one service don’t negatively affect others.

Production databases use autoscaling with minimum limit around 2 CUs and a higher maximum limit to handle traffic spikes.

All non-production environments = 1 Neon project. 

When moving to Neon, Invenco consolidated all non-prod services into a single Neon project. Why: this approach allows for better management of ephemeral environments through branching workflows.Testing data is loaded once into the main staging branch, with child branches created as needed for ephemeral environments. Non-production databases take advantage of scale-to-zero to save costs when they’re not being used.

Migrating progressively with minimal downtime 

For migrating services from Aurora to Neon, Invenco initially used AWS DMS but shifted to logical replication as a migration strategy as soon as this feature was stable in Neon. This has been critical for Invenco, allowing them to progressively migrate their services with minimal downtime: 

1. They enable logical replication in their Aurora instance (creating a publication) 
2. They create a subscription in a Neon project 
3. The replication process begins to copy data from Aurora to Neon in the background 
4. Once databases are in sync, a controlled switch can be performed—e.g. the source can be switched to read-only mode, letting the final changes replicate, and pointing the application to Neon 

Invenco also uses logical replication for their BI workflows, streaming data from Neon into Fivetran and Kafka for analytics and event-driven operations.

Get started 

If you’re also suffering with Aurora Serverless v2 and got curious about Neon, create a Free account and get a first feel for the platform.

Thank you to Invenco for sharing their story. Check out their case studies to learn more about their services.