AWS Database Blog

How Vestiaire Collective achieved near-zero downtime RDS for MariaDB upgrades with Amazon RDS Blue/Green Deployments

Vestiaire Collective is a leading global platform for pre-owned luxury fashion. The company achieved near-zero downtime when upgrading its Amazon Relational Database Service (Amazon RDS) for MariaDB fleet by using Amazon RDS Blue/Green Deployments. Vestiaire Collective is operating across 50 countries with over 7.5 million members and 30,000 new daily listings. The company follows a sustainability-focused philosophy called Think First, Buy Second, connecting buyers and sellers of secondhand luxury and designer items through a digitally verified and AI-curated marketplace.

As a 24/7 global ecommerce platform, Vestiaire Collective relies on RDS for MariaDB to power its core monolithic application. This application is the backbone of every purchase, listing, and transaction on the platform. When their production RDS for MariaDB fleet on version 10.6 approached its end-of-support date, the engineering team faced a challenge: upgrade across two major versions while maintaining near-zero downtime during peak sales season.

In this post, we share how Vestiaire Collective used Amazon RDS Blue/Green Deployments combined with AWS Countdown Premium to execute a two-phase upgrade from MariaDB 10.6 to 11.4. The team achieved a 94-second switchover in the first upgrade and only 7 seconds with no write downtime noticeable to customers in the second. This was the lowest-downtime database maintenance event in the company’s five-year history.

The challenge

Vestiaire Collective’s production RDS for MariaDB cluster consisted of a db.r7g.12xlarge primary instance with eight read replicas. This cluster supports the core monolithic application that powers the entire business. Any extended downtime means customers cannot purchase items, complete transactions, or browse listings. For a platform serving millions of users across multiple time zones, downtime is equivalent to business down.

The team faced several compounding pressures:

  • End-of-support timeline: Support for RDS for MariaDB 10.6.x was nearing its end and the specific minor version 10.6.19 would be deprecated as early as March 2026.
  • Peak season timing: The upgrades needed to happen during the fall 2025 peak sales season.
  • AWS Database Migration Service (AWS DMS) dependency: The RDS for MariaDB instance served as a source for two AWS DMS tasks, adding complexity to any upgrade path.
  • Performance requirements: The team wanted to simultaneously upgrade instance class from R7g to R8g for improved performance and cost efficiency.

Evaluating upgrade approaches

Before selecting RDS Blue/Green Deployments, the team evaluated alternative upgrade methods:

  • In-place upgrade: Would require several hours of downtime, which is unacceptable for a 24/7 global platform during peak season.
  • Upgrade with AWS DMS: Evaluated but not pursued because of the complexity of maintaining replication consistency across the upgrade.

Testing in lower environments (staging and QA) confirmed that RDS Blue/Green Deployments provided the safest path with the least downtime. The team upgraded their non-production environments first, validating application compatibility before applying the process to production.

Why Amazon RDS Blue/Green Deployments

The team chose RDS Blue/Green Deployments for three key reasons:

  1. Minimal disruption during peak sales season. RDS Blue/Green Deployments typically deliver a switchover with minimal downtime versus several hours of downtime required by an in-place upgrade. Protecting peak season revenue made this the clear choice.
  2. Performance stability from the moment of switchover. The multi-hour Amazon EBS volume hydration process happens entirely on the standby (green) environment before it receives any customer traffic. The green environment gives you time to hydrate storage and warm the buffer pool before it takes traffic, avoiding potential performance degradation.
  3. Risk mitigation with full rollback until switchover. Blue/Green allowed the team to run the upgraded environment in parallel with real production write traffic through binlogs for over a week before switching over. This validated application compatibility, query performance, replication accuracy, and DMS task continuity. In-place upgrades offer limited rollback options once applied. Blue/Green provided a tested, proven path with zero cascading failure risk.

Solution overview

Vestiaire Collective executed a two-phase upgrade strategy: first upgrading to MariaDB 10.11.14, and then to MariaDB 11.4.9. This isolated major engine version changes, following a recommended best practice.

Phase Date Upgrade Path Additional Changes Switchover Time
Upgrade 1 October, 2025 MariaDB 10.6.19 → 10.11.14 Instance class: db.r7g.12xlarge → db.r8g.12xlarge ~94 seconds
Upgrade 2 December, 2025 MariaDB 10.11.14 → 11.4.9 Engine version only ~7 seconds

The entire project spanned from October to December 2025, covering 1 primary instance, eight read replicas, and two DMS tasks. The following architecture diagram shows Vestiaire Collective’s application infrastructure on AWS.

Vestiaire Collective application infrastructure on AWS, showing the Amazon RDS for MariaDB primary instance, eight read replicas, and two AWS DMS tasks

Figure 1: Vestiaire Collective application infrastructure on AWS

Upgrade 1: MariaDB 10.6 to 10.11 with instance class change

The first upgrade combined a major engine version change with an instance class migration (a combination that would be difficult to achieve with minimal downtime using traditional in-place methods).

Pre-switchover preparation

The team followed a methodical preparation timeline:

  • Friday: Completed storage scaling to 5,500 GiB for all green environment instances and verified storage optimization across the fleet.
  • Monday: Performed InnoDB cache warming on the green environment. This prevented initial post-switchover latency caused by filling an empty buffer pool. Performed manual backups of the blue primary instance.
  • Tuesday (switchover day): Ran final pre-switchover health checks (SHOW PROCESSLIST, SHOW ENGINE INNODB STATUS) and initiated the switchover at 04:00 UTC with a 5-minute timeout window.

Switchover results

The switchover completed in approximately 94 seconds, well within the expected 1–5 minute window. Application traffic validation and monitoring began immediately afterward, with DMS tasks managed as required post-switchover. To maintain DMS tasks, they were stopped before switchover and then resumed from a new binlog position after the switchover.

Upgrade 2: MariaDB 10.11 to 11.4

Building on the success and lessons of the first upgrade, the second phase focused solely on the engine version upgrade from 10.11.14 to 11.4.9.

The results exceeded expectations: the total switchover time was approximately 7 seconds, with no noticeable write downtime at the database level. The database was accepting read and write operations immediately, though DNS propagation required additional time.

This was the lowest-downtime database maintenance event in Vestiaire Collective’s five-year history with AWS. The downtime was so minimal that their internal monitoring tools did not trigger a single alarm during the second upgrade event.

Using AWS Countdown Premium

AWS Countdown Premium provided critical support across both upgrades and the intervening peak sales period. The Countdown Premium engineer joined weekly cadence calls with Vestiaire Collective’s team to stay aligned on preparation and next steps. In addition, Countdown Premium provided:

  • Operational Readiness Review (ORR): A review of the RDS for MariaDB environment (including the primary instance and eight read replicas) was performed across key pillars including resiliency and high availability, observability, operations, and performance.
  • Upgrade runbook planning: Working with the customer, the Countdown Premium engineer helped refine the upgrade runbook to reduce potential risk, including pre-staging DB backups, validating replication health, and handling active DB write operations pre-switchover.
  • Upgrade 1 (October, 2025): 24-hour standby support coverage with RDS for MariaDB and DMS engineers on call. A war room call bridge was established for real-time coordination.
  • Peak Sales Event (November, 2025): 12-hour standby support with RDS database engineers proactively monitoring Amazon CloudWatch metrics. A dedicated war room call and formal communications channel helped verify no issues went undetected.
  • Upgrade 2 (December, 2025): 24-hour standby support with the same war room coordination model.
  • Post-event Countdown Premium report: A post-event Countdown Premium report was delivered capturing detailed metrics analysis for each upgrade, comparing performance in the week before and the week after each upgrade event to confirm stability and surface any regressions.

The team also used Slack External Connect as an ongoing communication channel between the AWS Countdown Premium engineer and the Vestiaire Collective team, which facilitated rapid troubleshooting, faster engagement, and easier collaboration. This allowed for quick identification and resolution of a Performance Insights query truncation issue discovered during the engagement.

Results

The Blue/Green deployment approach delivered measurable improvements across availability and operational confidence. Additionally, the engine version upgrade and instance class change provided significant performance improvements:

Metric Result
Upgrade 1 switchover time ~94 seconds
Upgrade 2 switchover time ~7 seconds
Query execution improvement Up to 40% for most-used queries (measured through benchmarking)
Post-upgrade CPU utilization Maximum 4.6%, with no bottlenecking
Read/write latency impact No significant changes. Spikes well below the 10 ms threshold

“We used to treat major database upgrades as multi-hour, all-hands events. Blue/Green let us combine a major engine upgrade with an r7g-to-r8g instance class change in a single 94-second switchover, then repeat the pattern in seven seconds two months later. We now have a proven playbook we’re applying to MariaDB 11.8 and to the rest of our infrastructure modernisation roadmap.”

— Hugo Almeida, VP of Engineering, Vestiaire Collective

Conclusion

In this post, you learned how Vestiaire Collective used Amazon RDS Blue/Green Deployments to upgrade their production MariaDB fleet across two major versions with near-zero downtime. You also learned how combining this approach with AWS Countdown Premium support enabled the team to safely execute these upgrades during peak sales season while simultaneously gaining up to 40 percent query performance improvements through an instance class migration and optimizing the queries.

Building on the success of their Fall 2025 upgrades, Vestiaire Collective has an ambitious infrastructure modernization roadmap:

  1. Continuous performance optimization: Ongoing monitoring and tuning using CloudWatch Database Insights, with a focus on query optimization as part of a broader monolith RDS optimization initiative.
  2. MariaDB 11.8 LTS upgrade: Evaluating an upgrade from 11.4 to MariaDB 11.8 LTS, using the same proven Blue/Green methodology.

To get started with Amazon RDS Blue/Green Deployments for your own database fleet, see the Amazon RDS Blue/Green Deployments documentation. For guidance on planning major version upgrades, see the Amazon RDS for MariaDB upgrade guide.

 


About the authors

Ejaz Azeem

Ejaz Azeem

Ejaz is a Senior DevOps Engineer at Vestiaire Collective, based in Berlin. He owns the company’s multi-cluster Amazon Elastic Kubernetes Service (Amazon EKS) platform and production RDS for MariaDB estate. He leads the high-stakes maintenance and upgrade work that keeps the core monolith available for 7.5 million members across 50 countries. He designed and led the RDS for MariaDB Blue/Green upgrade program, delivering Vestiaire Collective’s lowest-downtime database upgrade in five years.

Yala El Feghaly

Yala El Feghaly

Yala is a Senior Technical Account Manager at Amazon Web Services (AWS). She works closely with enterprise customers to accelerate cloud adoption, architectural excellence, and operational efficiency. As a trusted technical advisor, she helps customers navigate complex cloud environments and implement AWS best practices to achieve their business objectives.

Ryan Moore

Ryan Moore

Ryan is a Technical Account Manager at AWS supporting ISV customers. He has also worked within the AWS database team for 3 years. Ryan is an Amazon Aurora MySQL and Amazon RDS for MySQL subject matter expert who helps customers build performant, scalable, and secure architectures in the AWS Cloud.