How Moovit Modernized Its Global Data Architecture to Scale Urban Mobility Intelligence
Moovit, a Mobileye company and global leader in Mobility-as-a-Service (MaaS) solutions, has successfully executed a comprehensive transformation of its data infrastructure, shifting from a monolithic Amazon Redshift environment to a sophisticated, multi-engine lakehouse architecture. This strategic overhaul, which reduced the company’s provisioned Amazon Redshift footprint by 50 percent, serves as a blueprint for high-growth technology companies struggling to balance the competing demands of massive data ingestion, real-time analytics, and operational cost efficiency.
The Evolution of a Global Mobility Platform
Since its inception in 2012, Moovit has expanded its footprint to over 3,500 cities across 112 countries, supporting more than 1.7 billion users in 45 languages. The application provides essential services, including trip planning, real-time transit updates, and mobile ticketing. Behind this interface lies a massive, high-velocity data platform that processes mobility, application, and operational telemetry.
For much of the past decade, this data was centralized within a single Amazon Redshift cluster. As Moovit’s user base grew by orders of magnitude, so did the complexity and volume of the underlying data. The cluster, which initially utilized DC2 nodes and eventually migrated to RA3 nodes to accommodate increased storage requirements, became the primary bottleneck for the organization’s engineering and business intelligence teams. By the mid-2020s, the "all-in-one" approach to data warehousing had reached its breaking point. Jobs were increasingly queued, service level agreements (SLAs) were being challenged, and the law of diminishing returns had set in; adding further nodes to the cluster failed to yield proportional performance improvements.
Chronology of the Transformation
The modernization effort began with a diagnostic phase, as the engineering team realized that treating their data warehouse as an "opaque stream" was no longer sustainable. The project unfolded across four distinct phases:
- Observability and Attribution (Q1–Q2): Before re-architecting, the team needed to understand precisely what was consuming compute resources. They implemented an automated query attribution framework, classifying every query by user, service account, and execution context. This allowed them to map exactly which workloads were driving costs and latency.
- Resource Cleanup (Q2): Before migrating, the team performed a systemic audit, identifying and decommissioning legacy reports and scheduled processes that had become obsolete. This "spring cleaning" phase removed approximately 7 percent of the platform’s overall CPU load.
- Proof of Concept (Q3): With a clear understanding of the most resource-intensive workloads—specifically, raw data aggregation and sessionization pipelines—the team launched a proof of concept (POC) using Amazon EMR Serverless and Spark SQL.
- Production Migration (Q4–Q1 of following year): Following the successful POC, the team began offloading heavy ETL workloads to Amazon EMR, while isolating BI serving and exploratory data science to Amazon Redshift Serverless and a right-sized provisioned Redshift cluster.
Data-Driven Decision Making
The decision to pivot to a multi-engine architecture was not based on intuition, but on a rigorous framework of metrics. The Moovit team utilized CPU time as the primary indicator of compute pressure. By leveraging Tableau to visualize query activity, they were able to differentiate between workloads that were "heavy by volume" (high throughput requirements) and those that were "inefficient by behavior" (poorly optimized or overly complex queries).
This granular visibility enabled the team to apply the right tool to the right problem. For example, raw data ingestion and heavy transformations—previously the primary source of contention—were found to be ideally suited for the distributed processing power of Apache Spark on Amazon EMR. Conversely, the curated data products required for executive dashboards and real-time BI were best served by the stability and security of a provisioned Amazon Redshift cluster.
Overcoming Technical Hurdles
The transition was not without significant technical challenges. During the early stages of the EMR POC, engineers observed that initial Spark jobs took approximately four hours to complete—a significant regression compared to the 30–40 minute window the jobs occupied on Redshift.
The team addressed this through a methodical diagnostic process. By adjusting executor memory allocation, optimizing data partitioning, and resolving discrepancies between Spark SQL and Redshift SQL syntax, they eventually reduced the execution time to approximately 10 minutes—surpassing the original performance benchmarks while using fewer resources. To ensure complete data integrity, Moovit implemented a rigorous validation process, comparing outputs across multiple dimensions, including record counts, null values, and schema consistency, before finalizing the cutover.
Impact of the Multi-Engine Lakehouse
The move to a multi-engine environment—consisting of Amazon Redshift, Redshift Serverless, and Amazon EMR—has fundamentally altered the platform’s cost-performance profile. The 50 percent reduction in provisioned Redshift capacity represents a massive optimization in operational expenditure, but the qualitative gains are equally significant.
- Predictable Performance: By isolating ad-hoc data science queries to Redshift Serverless, the company eliminated the risk of exploratory work impacting production BI dashboards.
- Operational Scalability: The move from EMR Serverless for development to EMR on EC2 for production provided the team with the flexibility to manage long-term infrastructure costs using existing compute reservations.
- Agility: The use of AI-assisted development tools like Claude Code and Cursor accelerated the SQL translation process, allowing the engineering team to focus on architecture rather than syntax debugging.
Broader Implications for Data Infrastructure
The Moovit case study highlights a growing trend in enterprise data management: the end of the "one-size-fits-all" data warehouse era. As organizations deal with increasingly diverse data types—ranging from structured transactional data to semi-structured IoT and mobility logs—the reliance on a single, monolithic engine often leads to technical debt and ballooning costs.
By decoupling the storage layer from the compute engine and routing workloads based on their specific resource requirements, Moovit has achieved a "Lakehouse" effect. This architecture provides the flexibility to incorporate new, purpose-built engines as they emerge without requiring a complete overhaul of the data stack. For instance, the company is already looking toward Amazon Redshift RG instances, which utilize AWS Graviton processors, as a future step to achieve even better price-performance ratios.
Conclusion and Future Outlook
Moovit’s journey serves as a powerful reminder that infrastructure modernization is rarely just about changing technology; it is about changing operational culture. By prioritizing visibility and measurement before migration, and by implementing a strategy of incremental, evidence-based optimization, the company successfully transitioned its global mobility platform into a modern, cost-efficient ecosystem.
The core lesson for other organizations is that the most effective data architecture is one that acknowledges the different requirements of its users. Whether it is the high-throughput processing needed for data engineering pipelines, the consistent performance required for business intelligence, or the bursty, flexible capacity required for data science exploration, the modern cloud stack offers specialized tools for each. As Moovit continues to scale, this multi-engine foundation ensures that they are not just keeping pace with data growth, but are strategically positioned to leverage that data for future innovation in urban mobility.
