Engineering Manager
In our last blog post about zero downtime Postgres migrations, we shared how we set up this process on the open-source tool, Bucardo. To recap, we outlined four necessary steps to doing this right:
This post dives into how we switched all our clients to a new database without any noticeable downtime.
🧰 How we used Bucardo for a zero-downtime PostgreSQL migration
Learn how we’r migrating our database using Bucardo, an open-source tool for replicating PostgreSQL data.
Smartcar has several clients that use the Postgres database. However, we use a centralized repository as a database package for all our dependent clients. This database package is in charge of actually creating and managing connections to the database and has all the configurations required to connect to the databases for all environments. That being said, our current architecture looks like this:
With the architecture above, it would only be possible to switch all our services to the new database with downtime. The process would include:
On paper, it sounds simple, but we have multiple services that connect to the DB — which means all systems would have to cutover simultaneously, which is practically impossible.
This is where we slightly modified our DB package so we could switch all connections over to the new database dynamically without any package updates or deployments.
We added a few lines of code in our DB package that would help us dynamically update the database connection configurations through any source — like a configuration management tool or, in our case, a separate database. To summarize, this is what the new code did:
We also added a few other niceties to the process:
Based on the updates above, our current architecture looks like this:
Now, all we had to do was ensure that the new connection details were inserted in Dynamo DB and that the interval value was shortened so it was small enough for the change to take over quickly.
When our systems were ready to switch the database over dynamically, we ran through the complete list of migration steps a few times.
We learned a few things along the way to make our process better, faster, and cleaner.
More for developers: 🪝 How to set up Smartcar's scheduled webhooks
Explore how to use Smartcar's schedule-based webhooks to fetch recurring data from vehicles connected to an app.
All the trial and error finally led to us having a strong, repeatable process for our database upgrades. In fact, we’ve already done three upgrades with it!
Even though we’re certain that this approach to migration will result in no downtime, we still continue to inform our users about database maintenance and give them a window where our systems could return errors. This is done solely to accommodate any unexpected events. We hope you keep this in mind too if you’re looking to try this out!
We’re looking forward to sharing more learnings with the developer community! Subscribe to our newsletter below to stay tuned to our blog and to share your thoughts on developer productivity or all things connected cars 🤓
Have a cool idea you want to explore with the Smartcar API? Head on over to our docs and create a developer account to retrieve your API credentials and get started with the integration!
Smartcar is the easiest way to integrate mobility apps and services with cars.