Linxup Eliminates Downtime, Increases Scalability and Easily Moves to the Cloud with EDB Postgres Distributed

About Linxup

Linxup develops vehicle and asset tracking solutions for fleets and service companies in a variety of industries. Linxup delivers powerful but easy-to-use GPS solutions through a software-as-a-service (SaaS) platform. Their data gives businesses the tools they need to improve fleet management, increase mobile worker productivity and reduce operating costs. 

The Challenge

Since 2011, Linxup has provided both companies and consumers the ability to track assets—especially vehicles—anywhere they go. Customers use the product for myriad use cases, such as employee time tracking for business owners; fleet management and route optimization for trucking, transportation and construction companies; and even parental monitoring of teen drivers.

“Because of the sort of clients we serve—businesses looking to ensure productivity of teams and accuracy of important shipments, mostly, but also parents who are entrusting their kids’ safety to our solutions—reliability is critical to our reputation. If our customers don’t think that Linxup will be able to serve them all the time, they’re gonna find an alternative,” explained Adam LaMore, Vice President of Engineering at Linxup.

That reliability is most critical when it comes to Linxup’s ability to manage the massive amount of data created by its tools. Today, the company captures inputs from its more than 200,000 devices deployed nationally, the majority of which send location data at all times of the day and night. 

“We’ve been using Postgres since before Linxup was even a product—the company previously had another application that we developed on Postgres,” said LaMore. “We’ve always been happy with its performance and capabilities, but as we released more devices into the field, we started to run into write scalability and database maintenance challenges that progressed beyond our ability to handle them.”

Linxup experiences growing pains

By 2019, Linxup was still on PostgreSQL 9.3, a version two-to-three years out of date. Explained LaMore, “Our SaaS application is an always-on app. We were stuck on 9.3 because major version upgrades were too disruptive. At 11 TB, it would have taken a couple of days of downtime to upgrade—which was unacceptable from a customer service perspective.”

In addition to the growing maintenance challenge such a scenario created, LaMore’s team was struggling to keep up with the rapid growth of their database. At the time, Linxup was managing its infrastructure on bare metal servers they owned that were hosted in a colocation facility. However, the company’s success had led to faster data growth than they had anticipated, resulting in an operational nightmare as the DBA team tried to keep up with the rising data archiving demands. 

The lack of scalable storage wasn’t the only problem that company growth prompted. With more than 200,000 devices out in the field, that means that during peak times, tens of thousands of devices are sending back tracking data simultaneously, with the intent of writing it to the PostgreSQL database. The team needed to find a way to horizontally scale the database’s write capacity to keep up with the demand.

Looking at their current trajectory and future goals, Linxup was able to outline three critical challenges:

• The need for hundreds of thousands of global inputs to write to the same database, potentially simultaneously
• A large and growing 11 TB database that couldn’t be upgraded due to the unacceptable downtime it would cause
• The growing operational and cost disadvantages associated with maintaining a private data center environment

In order to address these challenges, Linxup would need a solution that could amplify PostgreSQL’s high availability and ensure consistent performance and support during essential maintenance processes such as upgrades. Simultaneously, the enterprise’s ongoing struggles with their current environment inspired them to attempt a migration to public cloud and the creation of a hybrid infrastructure that could more effectively handle their growing database needs. Whatever high availability solution they adopted would need to be able to ensure operational consistency over the course of such an extensive migration. 

That’s why they turned to EDB

The Solution

While LaMore had considered traditional approaches to solving the write scaling issue that came with the organization’s rapid growth, many of the solutions resulted in either unreasonable compromises or a complete rewrite of the company’s applications. As such, it quickly became clear that another solution was necessary. 

LaMore had considered EDB Postgres Distributed in the past, but the initial technology had not been a good fit for the application.

“Around the time that we were really facing some very undesirable decisions, EDB spoke with us about the new and expanded capabilities of Postgres Distributed,” remembered LaMore. “We took a new look at the technology and realized that with some modifications, this could easily be a solution to these major issues we were facing.”

How Linxup harnessed EDB Postgres Distributed

More than 90% of Linxup’s data is time-series data, collected constantly from its hundreds of thousands of tracking devices and kept in production for two years. As the company grew its customer base, the rate and volume of data capture exponentially increased, leading to the write scaling issue.

This made it difficult, if not near impossible, for all of Linxup’s existing applications to access the data they required—such as customer information and configuration specifics. With EDB Postgres Distributed, however, LaMore and his team had access to a feature known as “replication sets,” which enabled their developers to control which node the set replicates to, on a table by table basis. 

By taking advantage of that feature and the other capabilities within EDB Postgres Distributed, LaMore was able to create a six-node, multi-master cluster that could support simultaneous writes from multiple nodes without resulting in conflict or performance issues. 

LaMore described the solution this way: “One of the new features of EDB Postgres Distributed was geo-sharding. Combined with replication sets, we were able to selectively choose some tables – customer data and configuration for example – that could be replicated across all six nodes, while our time-series data was split into two shards. 

“Within a three-node shard, we have strict consistency and immediate replication, but have opted for eventual consistency across the two shards. That architecture enables us to reduce application changes while setting ourselves up for any future horizontal scalability needs. As a shard gets busy/full, we can break off customers into more shards while still maintaining a single database. Meanwhile, applications that don’t need to access tracking data can point to any of the nodes anywhere.”

With this new highly available infrastructure in place, Linxup was not only able to achieve their initial goals, but exceed them.

 

The Results

While they were deploying EDB Postgres Distributed, Linxup was able to upgrade from PostgreSQL 9.3 to PostgreSQL 11 without any downtime. Supercharging their database environment, this upgrade combined with Postgres Distributed’s new features led to a dramatic improvement in their application’s horizontal write scalability. 

On top of that, the enterprise retained confidence in consistent performance across the organization, no matter future growth demands.

“With write scalability issues solved for the foreseeable future, we’re able to keep the database up to date with the latest version of PostgreSQL without taking the database offline. We also have a much more robust and seamless disaster recovery set up than before,” LaMore told us.

With the PostgreSQL upgrade in their rearview mirror, Linxup turned to cloud migration—a journey which EDB Postgres Distributed had allowed them to accelerate

From on-prem, to hybrid cloud, to a full cloud environment

Initially, Linxup planned to migrate their database infrastructure to a hybrid cloud environment, keeping some of their physical servers, while adopting a public cloud architecture in tandem. With the backing of their highly available Postgres, they were able to do this with ease—and almost no downtime.

As a starting point, the business kept one cluster in their original co-location facility and established a new second cluster in Google Cloud.

“This architecture solved several challenges at once,” explained LaMore. “By migrating to a hybrid cloud approach, we were able to begin to offload server maintenance and storage considerations so I could focus my team on higher value work.”

Initially, Linxup had considered pausing here, confident that, in the future, they’d have a framework to migrate the remainder of their clusters and deploy a fully cloud infrastructure. However, following some failures among their bare metal servers, the organization decided to execute that migration well ahead of schedule.

“We always knew that the eventual goal was to be totally in the cloud,” LaMore said. “It’s easier, much simpler, much faster—and we saw that even when we were still hybrid.”

But their on-premises servers had begun to complicate the possibility of upgrading, and—while Google Cloud adapted to their continued growth without any trouble—the organization had to keep adding external storage applications to ensure their servers could keep up.

LaMore put it vividly: “It was like playing Tetris with the disc space of our database.”

And so, Linxup said goodbye to their hybrid architecture—confident in the full potential of the cloud, and knowing that EDB’s solutions would help them maintain database performance to their standards over the course of their migration. In October of 2021, Linxup boasted a fully cloud PostgreSQL infrastructure.

Since then, LaMore attested: “Everything’s gone even smoother.”

Linxup takes advantage of EDB’s expertise

At every stage of Linxup’s journey with EDB, the company took consistent advantage of EDB’s team of experts to support them. During the initial rollout of EDB Postgres Distributed, LaMore and his team uncovered an idiosyncrasy in the way the application handled node IDs that conflicted with the organization’s new architecture. The EDB team collaborated with the Linxup team to isolate the issue and were able to propose and develop a solution that minimizes changes to Linxup’s applications. 

Currently, EDB’s team also helps manage and maintain the database on a day-to-day level, alerting Linxup of unusual activity, maintenance needs and when they’re running low on disk space, for example. That partnership has freed up LaMore’s small development and operations team to focus on customer-facing advancements.

The Future

As Linxup continues to grow, the enterprise looks to EDB and PostgreSQL to support their ongoing evolution. Recently, they began executing their latest PostgreSQL upgrade to version 14, confident that—with EDB Postgres Distributed—they’d continue to see zero downtime.

For an organization with so many wide-ranging applications and use-cases as Linxup, having that confidence is critical. Their data drives the productivity and success of teams and individuals across industries. From the very beginning, EDB wanted to ensure Linxup could fulfill that mission to the highest degree.

LaMore concluded, “EDB’s solution has been working exactly as we had hoped. From a performance perspective, we haven’t had any of those bad days that we used to have where things got overloaded, and we were scrambling to find a solution. Performance has remained consistent, reliability has improved, and we now have a database that can support all our future growth plans.”

Do you have an EDB Postgres success story you want to share? Get in touch with us via our website or at success-stories@enterprisedb.com