AWS Database Blog
Migrating mission-critical payments at Nubank to Amazon Aurora PostgreSQL
Nubank is one of the world’s largest digital banks, serving approximately 135 million customers across Brazil, Mexico, and Colombia. Operating NuPay, its digital payment solution that processes millions of daily customer-to-business transactions, Nubank faced infrastructure challenges with queries taking over 13 minutes to complete, replication lag exceeding 4 minutes at peak times, and regulatory constraints for any planned downtime.
Managing payment infrastructure at scale presents unique challenges that impact both performance and operational efficiency. In this post, we share the technical and operational challenges Nubank faced with self-managed PostgreSQL, the evaluation criteria they established for selecting database solutions, and the results from their successful migration to Amazon Aurora PostgreSQL-Compatible Edition. Nubank achieved up to 1,900x query performance improvements in specific cases.
Business challenge
The NuPay team’s objective is to build payment infrastructure that accelerates developer productivity, reduces operational overhead, delivers consistent and reliable performance under varying loads, and provides scalability to support growing transaction volumes.
Managing 7.5 TB of payment data with over 31 billion rows across all tables on self-managed PostgreSQL created operational inefficiencies that affected both infrastructure teams and the developer community. The infrastructure team was burdened with manual deployment, patching, scaling, and maintenance activities while managing complex capacity planning requirements.
The developer’s experience suffered under this operational burden. Brazilian Central Bank regulatory requirements mandated 30-day advance notice to companies or enterprises for any planned downtime, turning routine infrastructure tasks into heavyweight coordination events. Manual scaling procedures during traffic spikes led to application performance degradation, as engineers could not respond fast enough to demand surges. Storage expansion to accommodate growing traffic required scheduled downtime windows, directly impacting application availability and service level agreement (SLA) compliance.
The payment application also faced critical performance challenges. Query performance tuning across billions of records became increasingly complex, with some queries taking over 13 minutes to complete. Replication lag exceeded 3–4 minutes at peak times, impacting real-time payment processing. Unexpected execution plan changes caused performance regressions that required constant monitoring and intervention.
Recognizing these challenges, the NuPay team initiated an evaluation of database solutions to consolidate their infrastructure and improve both operational efficiency and developer experience.
Database evaluation criteria
Nubank established an evaluation framework across four key dimensions aligned with their team principles.
First, for developer productivity, the solution required PostgreSQL compatibility to preserve developer expertise, support application portability, and integrate with existing business intelligence (BI) and developer tools all without disrupting established workflows.
Second, their operational efficiency requirements focused on reducing management complexity through automated patching, backups, and failure detection. Nubank needed full infrastructure abstraction that removes capacity planning, storage resizing, and infrastructure management concerns, so engineers can focus on innovation rather than maintenance.
Third, the team’s performance reliability criteria emphasized consistent, predictable database behavior under production workloads. Nubank required high availability (HA) that supports their stringent uptime requirements, performance consistency that matches or improves upon existing infrastructure under varying load patterns, and native read replica support without the overhead of managing replication topology. The database engine must sustain low-latency responses even during maintenance operations, making sure end-user experience remains unaffected.
Finally, scalability considerations centered on cost-efficiency through better resource utilization and pay-as-you-go pricing, combined with the ability to scale with minimal manual intervention and accommodate future use cases as Nubank’s payment operations continue to grow.
After evaluating multiple database solutions against these criteria, Nubank selected Aurora PostgreSQL as the preferred database solution for its payment infrastructure.
Why Nubank chose Aurora
These evaluation criteria led Nubank to Aurora PostgreSQL, which addressed their specific infrastructure requirements through several key capabilities.
Nubank deployed Aurora PostgreSQL-Compatible Edition 14.17, matching their source PostgreSQL version for full compatibility during migration while using Aurora-specific features including Query Plan Management, shared buffer optimization, and automated storage scaling.
Meeting payment infrastructure performance requirements
The evaluation revealed that NuPay’s payment application required a database solution that could handle massive scale (7.5 TB, over 31 billion rows) while maintaining sub-second query performance for real-time payment processing. The Aurora architecture delivered the performance improvements needed through the following features:
Log-based write operations – Aurora uses a log-based approach that sends only redo log records to the distributed storage layer instead of full data pages. These log records are written in parallel to a quorum of storage nodes across three Availability Zones (requiring four of six nodes to acknowledge), delivering higher write throughput and lower latency while maintaining durability.
Shared storage architecture – Aurora separates compute and storage layers through a fault-tolerant distributed system that spans three Availability Zones in an AWS Region. This architecture allows Aurora to serve reads locally while maintaining data consistency. The database engine allocates 75 percent of instance memory to shared buffers by default, significantly higher than the typical 25–40 percent in standard PostgreSQL. This is possible because Aurora avoids double buffering, where data is cached redundantly in both the PostgreSQL shared buffers and the OS page cache. Clearing more memory for query processing allows more queries to be served from memory rather than disk.
Read replicas – Aurora read replicas serve as automatic failover targets. They share the same storage volume as the writer instance while consuming the log stream asynchronously, with lag usually less than 100 milliseconds. When the primary writer instance experiences issues, Aurora automatically fails over to one of up to 15 read replicas within the same Region with no loss of committed transactions. Additionally, read replicas incur no additional storage costs because instances share the underlying storage volume.
Query Plan Management – The Aurora Query Plan Management feature helps prevent execution plan regressions that had previously caused performance issues in production, facilitating consistent query performance across billions of payment records.
Alleviating operational overhead
Aurora is a fully managed relational database engine that alleviates the manual deployment, patching, scaling, and maintenance efforts previously required with self-managed PostgreSQL databases.
Storage automatic scaling – Aurora automatically scales storage from 10 GB to 256 TB in 10 GB increments without downtime or performance impact and dynamically resizes downward to minimize storage charges based on actual usage, alleviating the capacity planning burden and storage expansion windows that previously disrupted payment processing.
Automated maintenance – The automated patching, backups, failure detection and failover reduced maintenance windows from 11 hours to 1–1.5 hours, helping Nubank meet their 30-day notification requirements to customers while maintaining regulatory compliance and minimal service disruption.
PostgreSQL compatibility – Developers can use their existing PostgreSQL expertise without retraining. Applications required minimal or no changes to application code during migration, preserving development velocity while teams maintained throughout the transition, and increasing rollout reliability during the maintenance window by using infrastructure changes instead of application-level changes.
Achieving cost-efficiency and security compliance
The pay-as-you-go pricing model improved cost efficiency through better resource utilization. Prior to the migration, NuPay’s transactional databases required three instances (one writer, one standby, and one read replica) since a dedicated standby instance was effectively mandatory for high availability. With Aurora PostgreSQL, the read replica serves as the high-availability failover target, significantly reducing the need for a separate standby instance. As a result, Nubank consolidated from three instances to two (one writer and one reader) while maintaining availability guarantees and improving overall performance. This architectural efficiency delivered an immediate 25 percent cost reduction post-migration, and following additional rightsizing and Reserved Instance commitments.
The built-in security features of Aurora align with Nubank’s financial services regulatory requirements, including encryption at rest using AWS Key Management Service (AWS KMS) with AES-256, and encryption in transit using SSL/TLS. Aurora also supports compliance certifications critical to financial institutions, including PCI DSS, SOC 1/2/3, and ISO 27001. Native integration with AWS CloudTrail and Amazon CloudWatch provided automated audit trails and monitoring capabilities required by the Brazilian central bank.
“Aurora PostgreSQL transformed how we think about database infrastructure. Its fully managed architecture, with automatic storage scaling, built-in Multi-AZ high availability, and fast automatic failover across Availability Zones gave us the resilience and performance our payment application demands at scale.”
“AWS DMS was equally strategic: it reduced our actual cutover time to just over an hour, well within our 5-hour maintenance window. The dedicated support from our AWS Solutions Architect and migration specialist gave us precise guidance on best practices and the confidence to modernize our payment infrastructure with zero data loss and minimal downtime.”
— Felipe Ziliotti, Engineering Manager, Nubank
Migration strategy
Nubank’s migration strategy used AWS Database Migration Service (AWS DMS) following industry best practices, supporting homogeneous migration from PostgreSQL to Aurora PostgreSQL, Change Data Capture (CDC) for minimal downtime, multiple parallel migration tasks for improved throughput, and continuous replication during the cutover period. The following diagram illustrates the migration architecture.
Figure 1: Migration architecture — PostgreSQL to Amazon Aurora PostgreSQL-Compatible Edition
The segmentation of the migration into 10 dedicated DMS tasks was driven by three factors. First, table-size isolation: the payment table alone accounts for approximately 3 TB, the orders table approximately 1.2 TB, and transaction table approximately 520 GB of the 7.5 TB total dataset, so dedicating individual tasks to large tables helps prevent any single table from blocking progress on others. 9 of the 10 tasks each contained a single table, while the tenth combined all smaller tables. Second, failure isolation: if one task fails, the remaining tasks continue unaffected, supporting targeted restarts without losing global progress. Third, independent CDC management: each task maintains its own replication slot, allowing independent catch-up per table group, critical for managing replication lag between full-load completion and the final cutover window.
Despite a 5-hour maintenance window allocation, the actual constraint time was only 1 hour and 7 minutes for the largest table and 40 minutes each for two smaller databases, completing all three migrations within a 3-hour total window, well ahead of schedule and in full compliance with the 30-day advance customer notification required under regulatory obligations.
Migration results
Nubank has successfully migrated their NuPay payment application from self-managed PostgreSQL to Aurora PostgreSQL. To validate the migration, Nubank’s engineering team conducted comprehensive performance testing using real production queries from their data teams, focusing on the heaviest and most critical workloads rather than synthetic benchmarks.
Query performance improvements
For the receipt applications, Nubank validated query performance using EXPLAIN ANALYZE across four distinct workload categories: large-scale historical scans (queries spanning multi-month windows over receipts and refunds tables), complex join operations (merchant lifecycle queries joining payments and payment orders), financial aggregation workloads (payment fee calculations and settlement batch processing), and full execution plan analysis (complete query plans with detailed timing breakdowns).
Large-scale historical scans: These queries retrieve high-volume transactional data across extended time windows, scanning millions of rows in receipts, refunds, and payment orders tables. A 2-month historical receipts scan now executes in 0.424 seconds on Aurora, compared to 13 minutes 38 seconds on self-managed PostgreSQL, a 1,900x improvement. A complex receipts query spanning similar data volumes dropped from 10 minutes 24 seconds to 0.293 seconds (2,100x faster). Refunds queries across the same window improved from 8 minutes 39 seconds to 13 seconds (40x faster). The most complex query in this category, a broad payment orders query, improved from 35 minutes 46 seconds to 28 minutes 18 seconds, delivering 1.26x faster performance.
Complex join operations: Merchant lifecycle queries involve multi-table joins across payments and payment orders for unpaid settlement batches within specific date ranges. The same operation that required 54 seconds on self-managed PostgreSQL completes in only 2 seconds on Aurora, a 27x improvement.
Financial aggregation workloads: Queries combining payments and payment fees data for settlement processing showed cache-dependent behavior. During cold-start scenarios, execution took 4 minutes 17 seconds versus 15 minutes 31 seconds on the previous application. After allowing the buffer cache to warm through three consecutive executions, performance stabilized: the same query that required 1 minute 36 seconds on self-managed PostgreSQL completed in only 3 seconds on Aurora (32x faster). This validated the importance of testing with warmed caches for complex aggregation queries critical to Nubank’s payment settlement operations.
Full execution plan analysis: When analyzing queries with EXPLAIN ANALYZE to capture detailed execution timing, Aurora PostgreSQL consistently outperformed self-managed PostgreSQL. Receipt queries with complete execution analysis saw a 62 percent reduction in execution time, completing in 2 minutes 25 seconds. Refunds queries completed in 2 minutes 13 seconds, down from 5 minutes 39 seconds (2.5x faster).
Across their production workload, Nubank observed an average 15–20 percent improvement in query performance when comparing Aurora PostgreSQL to their previous self-managed environment, with specific queries delivering orders-of-magnitude gains depending on access patterns and data characteristics.
End-to-end service latency comparison
Beyond individual query performance, Nubank measured end-to-end service latency across their entire NuPay system to assess real-world impact. Comparing production latency against the self-managed baseline from one week prior, Aurora PostgreSQL showed consistent improvements across multiple service categories:
- APIs: Checkout, payments, internal, and backoffice endpoints.
- Background jobs: Settlement and general transactional jobs.
- Event consumers: Message processing pipelines.
Line chart comparing Orders service latency over 48 hours
Line chart comparing Payments service latency over 48 hours
Line chart comparing Refund service latency over 48 hours
Line chart comparing Fees Management service latency over 48 hours
For most services analyzed, the blue line (Aurora PostgreSQL) remained consistently below the orange dotted line (self-managed PostgreSQL), indicating measurable end-to-end latency improvements after migrating to Aurora. This reduction in application-level latency directly translated to faster payment processing, improved customer experience, and enhanced system responsiveness across Nubank’s 135 million customer base.
Additionally, Nubank observed improvements in database replication consistency. Previously, replication lag between cluster instances could exceed 3–4 minutes during peak times, causing visible inconsistencies for customers during payment authorization and state change operations. After migrating to Aurora, typical replication lag dropped to only a few seconds between the writer and reader instances, significantly reduced customer-facing consistency issues.
The migration validated that Aurora PostgreSQL’s architecture, with its decoupled compute and storage layer and distributed storage across multiple Availability Zones, could handle Nubank’s massive scale while delivering superior performance, reduced operational complexity, and enhanced reliability for mission-critical payment processing operations.
Considerations and limitations
While Aurora PostgreSQL delivered significant improvements for Nubank’s payment infrastructure, results can vary based on workload characteristics. Transactional workloads with frequent point lookups and index-driven queries benefit most from the shared buffer architecture and log-based writes, while complex analytical aggregations across large datasets may show more incremental improvements. For large-scale migrations involving terabytes of data, plan for appropriate DMS expertise and coordination with your AWS account team. Verify feature availability for your specific Aurora PostgreSQL target version in the Aurora PostgreSQL release notes.
Conclusion
In this post, we walked through how Nubank’s migration from self-managed PostgreSQL to Aurora PostgreSQL demonstrates a comprehensive approach to database modernization that delivers measurable results across performance, cost, and operational efficiency. The migration achieved up to 1,900x query performance improvements in specific scenarios, with an average 15–20 percent improvement across production workloads and a 25 percent cost reduction.
Following their migration efforts to Aurora PostgreSQL, Nubank has alleviated performance bottlenecks while providing predictable sub-second latency patterns for payment processing that supports their 135 million customers across Latin America. These improvements, combined with the fully managed capabilities of Aurora and automatic scaling, have established Aurora PostgreSQL as the foundation for Nubank’s continued growth in digital banking operations.
With Aurora PostgreSQL as their foundation, Nubank continues exploring Graviton processors for enhanced price-performance, optimized reads for analytics workloads, and ongoing PostgreSQL version upgrades for latest features and security enhancements.
To evaluate Aurora PostgreSQL for your own database workloads, refer to Getting started with Amazon Aurora and Best practices with Amazon Aurora PostgreSQL to understand implementation guidance and optimization techniques. For step-by-step migration guidance, see Migrating data to Amazon Aurora.