"Netflix has completed a major consolidation of its relational database infrastructure onto Amazon Aurora, reporting performance improvements of up to 75% and a 28% reduction in costs. The streaming giant's move from self-managed PostgreSQL on EC2 to the managed Aurora service highlights a broader industry trend toward offloading operational overhead to cloud-native database platforms. Facing challenges with a fragmented database landscape, Netflix's Online Data Stores (ODS) team struggled with the operational toil of managing deployed custom binaries, patching, and manual scaling."
"The results of the migration were immediate and significant across critical microservices. Spinnaker, Netflix's continuous delivery platform, saw a 50% reduction in average latency, dropping from 67.57ms to 41.70ms. The Policy Engine service experienced even more dramatic gains, with latency on key endpoints falling by 75%, from 26.72ms to 6.51ms. These improvements are attributed largely to Aurora's architecture, which separates compute from storage and utilises a log-based write approach."
"This design allows the database to allocate 75% of instance memory to shared buffers, significantly more than the typical 25-40% in standard PostgreSQL. Ammar Khaku, Staff Software Engineer on the Netflix Online Data Stores team, commented on the operational shift: "We no longer have to build and deploy custom binaries on EC2 with internal security and metrics-related patches. Switching to off-the-shelf managed Aurora PostgreSQL lets us focus on business logic and data access patterns.""
Netflix migrated its relational databases from self-managed PostgreSQL on EC2 to Amazon Aurora PostgreSQL-Compatible Edition, consolidating infrastructure and reducing costs by 28%. The Online Data Stores team moved to managed Aurora to eliminate operational toil from custom binaries, patching, and manual scaling while preserving PostgreSQL compatibility for developers. Migration produced large latency reductions: Spinnaker latency fell 50% (67.57ms to 41.70ms) and the Policy Engine saw 75% reductions (26.72ms to 6.51ms). Aurora's separation of compute and storage, log-based writes, and ability to allocate 75% of instance memory to shared buffers drove performance gains.
Read at InfoQ
Unable to calculate read time
Collection
[
|
...
]