Best Practices for Connection Management and Memory Allocation
summary
Airwallex migrates a Postgres/Cassandra mix to YugabyteDB and shows concrete wins: server-side pooling via Connection Manager (tech preview) yields 5–20× faster connection creation and supports about 5× more concurrent connections, plus session parameters and prepared-statement support. Memory tuning example uses a 3-node cluster on 8 vCPU / 32 GB nodes: Postgres backends cost ~15–30 MB each (rising to ~30–60 MB with catalog cache), tablet overhead ≈7 MB per tablet, forcing tradeoffs between number of physical connections and tablet count.
AI-written summary · about
chapters (12)
- 0:00Introduction
- 0:25Agenda
- 1:52AX business overview
- 3:59Database challenges at AX
- 5:27Why YugabyteDB was chosen for AX
- 6:53Smart driver for HA/low latency
- 7:56Query tuning best practices
- 10:07YugabyteDB roadmap
- 12:13Connection latency comparison
- 12:56Concurrent connection support
- 13:16Memory allocation strategies
- 17:37Q&A
related talks
51mEmbrace, Extend, Evolve - Making PostgreSQL Work for a Cloud Native World
51mJump Start Your Developer Journey in 60 Minutes: Go from 0 to Expert
26mIntroducing YugabyteDB for PostgreSQL Users
24mLessons Learned from benchmarking and profiling distributed PostgreSQL
36mBest Practices in PostgreSQL Tuning: Navigating Key Performance Bottlenecks in the Cloud
48mPractical Memory Tuning for PostgreSQL
25mYugabyteDB Technical Overview
26mLinux and PostgreSQL in the Multiverse of Connections