Vacasa, a leading vacation rental management platform in North America, is revolutionizing the vacation rental experience with advanced technology and expert local teams. Homeowners benefit from increased income through Vacasa’s expert revenue management teams, and guests can enjoy thousands of homes across the US, Belize, Canada, Costa Rica, and Mexico, with 24/7 central and local support. Vacasa’s properties can be booked on Vacasa.com, the Vacasa Guest App, and through partners including Airbnb, Booking.com, and Vrbo.
In the competitive short-term vacation property management industry, efficient systems are critical. To maintain its edge and continue providing top-notch service, Vacasa needed to modernize its primary transactional database to improve performance, provide high availability, and reduce costs. In this post, we share Vacasa’s journey from Amazon Relational Database Service (Amazon RDS) for MariaDB to Amazon RDS for MySQL, and finally to Amazon Aurora, highlighting the technical steps taken and the outcomes achieved.
Solution overview
To meet growing demand, Vacasa embarked on a journey to modernize its homegrown property management system (PMS). This system was based on a monolithic architecture with a single massive database serving all their needs. The goal was to transition to a more modern microservices architecture with decoupled components and purpose-built data stores. As part of this journey, the monolithic database encountered challenges during modernization, which followed the strangler fig pattern—an incremental approach to modernizing legacy systems by gradually adding new functionality alongside the old system and eventually phasing out the legacy components. Both legacy and new microservices components interacted with the central database, making scalability, reliability, and cost-effectiveness critical. The following diagram illustrates the high-level legacy architecture of Vacasa’s PMS components and microservices.
This PMS database stored critical property data, including unit metadata, addresses, amenities, restrictions, and property descriptions. It also managed property availability information, functioning like a large-scale calendar that handled reservations over an 18-month period for all properties.
Amazon RDS for MariaDB enabled Vacasa to effortlessly grow to their current scale. However, at their current growth rate, Vacasa would exceed the capabilities of a classic managed database within a few months. This meant that Vacasa had to rethink their architecture from the ground up, and design for higher-performance and scalability, as well as streamline their schema management to support the company’s growing property portfolio. Additionally, Vacasa aimed to achieve real-time data availability and more efficient cost management as the system scaled. The following diagram illustrates Vacasa’s PMS central database state before modernization.
Efficient operation and cost optimization were key because the transition to microservices meant each service would have its own database. Scalability was a primary objective, especially with the growing number of homeowners and the increasing load from additional properties. To support business growth, the goal was to provide smooth operation, enhance performance, and improve cost-efficiency within the new microservices architecture, all while maintaining the high level of service expected by customers.
To achieve these objectives, Vacasa choose to modernize its platform using Aurora. Aurora offers scalability, high availability, and cost-efficiency, making it ideal for their modernized architecture. Its distributed replica design allowed Vacasa to handle increasing workloads without performance issues, and automatic replication across multiple Availability Zones provided data durability and minimized downtime, which is critical for managing real-time property availability and reservations. To achieve a smooth transition, Vacasa adopted a two-step migration process, moving first from Amazon RDS for MariaDB to Amazon RDS for MySQL, and then to Amazon Aurora MySQL-Compatible Edition.
This staged approach was chosen for several reasons. Migrating directly from MariaDB to Aurora could introduce compatibility issues, particularly with features like dynamic columns. By first transitioning to Amazon RDS for MySQL, Vacasa maintained feature compatibility and addressed any potential issues in a controlled environment. Additionally, this gradual migration allowed for data validation and application testing, minimizing the risk of data loss and achieving a smoother transition with less downtime, ultimately supporting Vacasa’s evolving needs.
Migrate from Amazon RDS for MariaDB to Amazon RDS for MySQL
The migration from Amazon RDS for MariaDB to Amazon RDS for MySQL was run using mydumper for the schema and initial one-time data transfer, combined with AWS Database Migration Service (AWS DMS) for ongoing replication or change data capture (CDC). The decision to use AWS DMS instead of native MySQL replication was driven by the need for granular monitoring and error handling. AWS DMS provided detailed monitoring through Amazon CloudWatch, enabling real-time visibility into replication performance, lag, and potential issues. The following diagram illustrates this migration approach.
Pre-migration phase
The pre-migration phrase includes the following steps:
- Use mydumper to create a schema and data dump of the RDS for MariaDB database. Process and import the dump files into the target database using myloader.
- Validate the data load, confirming indexes and foreign keys are correct. Drop triggers on the target database to avoid potential errors or performance issues caused by trigger execution during data loading.
- Apply security group rules to the RDS for MySQL database to match the RDS for Maria DB database.
- Provision an AWS DMS replication instance and create a migration task for CDC to provide ongoing replication from the source to the target database.
Migration and cutover phase
The migration and cutover phase includes the following steps:
- Pause deployment jobs to prevent new changes to existing data during the cutover.
- Complete any outstanding writes to the source database and confirm the migration task is caught up with all changes.
- Pause application traffic and close connections to the source database.
- Create a final snapshot of the source database (Amazon RDS for MariaDB) before cutover.
- Reactivate the triggers on the target database.
- Redirect application services from the source database endpoints to the target database endpoints.
- Restart application services and validate traffic on the target database for both primary and replicas through functional tests.
- Reactivate deployment jobs and monitors.
Migrate from Amazon RDS for MySQL to Aurora MySQL-Compatible
For this migration, an Aurora instance was added to the RDS for MySQL database as an external replica, providing a reliable and high-performance solution while optimizing costs by eliminating the need for an additional AWS DMS replication instance. This direct replication setup facilitated efficient data transfer and synchronization between the two databases, providing minimal disruption and maintaining data integrity throughout the transition. The following diagram illustrates this approach.
Pre-migration phase
The pre-migration phrase includes the following steps:
- Use mydumper to create a schema and data dump of the RDS for MySQL database. Process and import the dump files into the target database using myloader.
- Validate the data load, confirming indexes and foreign keys are correct.
- Apply security group rules to the Aurora database to match the RDS for MySQL database.
- Connect the Aurora primary as an external replica to the RDS for MySQL source database to start the replication
- Set up additional replicas on the Aurora database a few days before the migration to provide sufficient time for testing and validation and to handle read traffic.
Migration and cutover phase
The migration and cutover phase includes the following steps:
- Pause deployment jobs to prevent new changes to existing data during the cutover.
- Complete any outstanding writes to the source database and confirm replication is caught up.
- Pause application traffic and close connections to the source database.
- Create a final snapshot of the source database (Amazon RDS for MySQL) before cutover.
- Stop replication and detach the target database from the source database.
- Redirect application services from the source database endpoints to the target database endpoints.
- Restart application services and validate traffic on the target database for both primary and replicas through functional tests.
- Reactivate deployment jobs and monitors.
If a rollback is needed during migration, such as when validation tests fail or unexpected issues occur, the strategy involves setting the target database to read-only, stopping connections, and redirecting application services to the source database. This is followed by validations, such as confirming data consistency and verifying application connectivity.
Current state and business impact
Before the migration, Vacasa’s database setup involved four RDS for MariaDB replicas, each dedicated to different teams and functions such as ETL (extract, transform, and load), admin tasks, and legacy systems. This configuration led to inefficient load balancing of read traffic, because each system interacted with its own replica, resulting in under-utilization and increased complexity.
Post-migration, Vacasa transitioned to Aurora, which features a single read-only endpoint with two replicas, significantly improving load distribution and efficiency. This shift allowed Vacasa to reduce the number of replicas while enabling auto scaling to handle increased traffic as needed, leading to substantial cost savings. The pay-as-you-use IOPS model further enhanced cost-efficiency by preventing the over-provisioning of resources. The following diagram shows the current database state after modernization.
One notable advantage of migrating to Aurora was the ease of handling database engine upgrades. Aurora simplified this process by enabling upgrades to be completed in minutes, minimizing downtime and allowing users to access the database during the upgrade. Whereas Amazon RDS for MySQL benefits from more frequent database engine updates and broader support for features such as JSON data types, the final transition to Aurora reduced replica lag and enabled real-time data availability and faster read performance. These changes resulted in a 35% performance boost in average application response times and a 48% reduction in database costs while maintaining 99.99% uptime for consistent and reliable access.
Several technical enhancements were also integrated post-migration. The use of Datadog for real-time system insights and proactive issue management was a crucial addition. The Aurora architecture allowed for dedicated replicas for specific services, optimizing critical operations.
Conclusion
Database modernization had a significant impact on Vacasa’s operations. Although the legacy Amazon RDS for MariaDB setup had been effective, migrating to an Aurora architecture provided even greater efficiency, enabling faster schema changes and reducing replica lag, which improved data accuracy and streamlined operations. Vacasa had not fully utilized reserved instances in their previous Amazon RDS setup; adopting Aurora with reserved instances led to a 48% cost reduction, giving Vacasa financial flexibility for reinvestment into other strategic initiatives.
The 35% performance improvement allowed the system to handle higher loads more effectively, enhancing both user experience and system reliability. The phased migration approach—from Amazon RDS for MariaDB to Amazon RDS for MySQL and finally to Aurora—proved to be a successful strategy, minimizing risks and disruptions. This enabled Vacasa to meet its growing demands in a more scalable and cost-effective manner. The technical enhancements and architectural improvements gained during the migration have positioned Vacasa for continued growth and operational excellence.
Now is the perfect time to explore how similar improvements can elevate your business. Take the next step toward optimizing your infrastructure by visiting the Aurora product page or checking out Amazon Aurora resources. Have questions or insights? Feel free to share them in the comments!
About the Authors
Pierre Stroot is a seasoned Senior Database Engineer at Vacasa with extensive experience in developing, optimizing, upgrading, securing, monitoring, migrating, and automating mission- critical production infrastructures in enterprise environments. He is known for his excellent communication skills, teamwork, technological innovation, and commitment to ongoing learning and growth.
Cristian Barrera is the Director of Engineering at Vacasa, based in Chile. He leads engineering teams responsible for the company’s core platform services, with a strong focus on cloud technologies, microservices, event-driven design, and scalable solutions. Cristian also manages the DevOps department, overseeing infrastructure operations across AWS and other SaaS providers. Additionally, he has spearheaded initiatives to enhance engineering excellence, knowledge sharing, and collaborative culture within the company.
Suresh Raavi is a Senior Solutions Architect at AWS, based out of Seattle. He is currently working with AWS enterprise customers to help them craft highly scalable, flexible, and resilient cloud architectures on their digital transformation journey in the cloud. He has amassed extensive experience in cloud technologies, automation, and infrastructure at various companies including Microsoft, holds numerous AWS certifications, and is a Dale Carnegie graduate in effective communications and human relations.
Source: Read More
