80 ਕਰੋੜ ChatGPT ਵਰਤੋਂਕਾਰਾਂ ਲਈ PostgreSQL ਨੂੰ ਸਕੇਲ ਕਰਨਾ

ਕਈ ਸਾਲਾਂ ਤੋਂ, PostgreSQL ਉਹਨਾਂ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਣ ਅੰਦਰੂਨੀ ਡਾਟਾ ਸਿਸਟਮਾਂ ਵਿੱਚੋਂ ਇੱਕ ਰਿਹਾ ਹੈ ਜੋ ChatGPT ਅਤੇ OpenAI ਦੀ API ਵਰਗੇ ਮੁੱਖ ਉਤਪਾਦਾਂ ਨੂੰ ਚਲਾਉਂਦੇ ਹਨ. ਜਿਵੇਂ ਜਿਵੇਂ ਸਾਡਾ ਵਰਤੋਂਕਾਰ ਅਧਾਰ ਤੇਜ਼ੀ ਨਾਲ ਵਧਿਆ ਹੈ, ਤਿਵੇਂ ਸਾਡੇ ਡਾਟਾਬੇਸਾਂ ਉੱਤੇ ਮੰਗ ਵੀ ਘਾਤਾਂਕ ਰੂਪ ਵਿੱਚ ਵਧੀ ਹੈ. ਪਿਛਲੇ ਇੱਕ ਸਾਲ ਵਿੱਚ, ਸਾਡੇ PostgreSQL ਲੋਡ ਵਿੱਚ 10x ਤੋਂ ਵੱਧ ਵਾਧਾ ਹੋਇਆ ਹੈ, ਅਤੇ ਇਹ ਅਜੇ ਵੀ ਤੇਜ਼ੀ ਨਾਲ ਵੱਧ ਰਿਹਾ ਹੈ.

ਇਸ ਵਾਧੇ ਨੂੰ ਝੱਲਣ ਲਈ ਆਪਣੇ ਪ੍ਰੋਡਕਸ਼ਨ ਇਨਫਰਾਸਟਰਕਚਰ ਨੂੰ ਅੱਗੇ ਵਧਾਉਣ ਦੇ ਸਾਡੇ ਯਤਨਾਂ ਨੇ ਇੱਕ ਨਵਾਂ ਨਤੀਜਾ ਸਾਹਮਣੇ ਲਿਆ: PostgreSQL ਨੂੰ ਬਹੁਤ ਵੱਡੇ read-heavy workloads ਲਈ ਭਰੋਸੇਯੋਗ ਢੰਗ ਨਾਲ ਸਕੇਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਜਿੰਨਾ ਬਹੁਤਿਆਂ ਨੇ ਪਹਿਲਾਂ ਸੰਭਵ ਨਹੀਂ ਮੰਨਿਆ ਸੀ. ਇਹ ਸਿਸਟਮ, ਜਿਸਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ University of California, Berkeley ਦੇ ਵਿਗਿਆਨੀਆਂ ਦੀ ਟੀਮ ਨੇ ਬਣਾਇਆ ਸੀ, ਸਾਨੂੰ ਇੱਕ ਹੀ primary Azure PostgreSQL flexible server instance⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਅਤੇ ਦੁਨੀਆ ਭਰ ਦੇ ਕਈ regions ਵਿੱਚ ਫੈਲੇ ਲਗਭਗ 50 read replicas ਨਾਲ ਵਿਸ਼ਾਲ ਗਲੋਬਲ ਟ੍ਰੈਫਿਕ ਸੰਭਾਲਣ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ. ਇਹ ਕਹਾਣੀ ਹੈ ਕਿ OpenAI ਵਿੱਚ ਅਸੀਂ ਕਿਵੇਂ ਕੜੀਆਂ optimizations ਅਤੇ ਮਜ਼ਬੂਤ ਇੰਜੀਨੀਅਰਿੰਗ ਰਾਹੀਂ 80 ਕਰੋੜ ਵਰਤੋਂਕਾਰਾਂ ਲਈ ਪ੍ਰਤੀ ਸਕਿੰਟ ਲੱਖਾਂ queries ਨੂੰ ਸਮਰਥਨ ਦੇਣ ਵਾਸਤੇ PostgreSQL ਨੂੰ ਸਕੇਲ ਕੀਤਾ. ਅਸੀਂ ਇਸ ਦੌਰਾਨ ਸਿੱਖੀਆਂ ਮੁੱਖ ਗੱਲਾਂ ਵੀ ਸਾਂਝੀਆਂ ਕਰਾਂਗੇ.

ChatGPT ਦੇ ਲਾਂਚ ਤੋਂ ਬਾਅਦ ਟ੍ਰੈਫਿਕ ਬੇਮਿਸਾਲ ਗਤੀ ਨਾਲ ਵਧਿਆ. ਇਸਨੂੰ ਸੰਭਾਲਣ ਲਈ ਅਸੀਂ ਐਪਲੀਕੇਸ਼ਨ ਅਤੇ PostgreSQL ਡਾਟਾਬੇਸ ਦੋਹਾਂ ਪੱਧਰਾਂ ਉੱਤੇ ਤੇਜ਼ੀ ਨਾਲ ਵਿਆਪਕ optimizations ਲਾਗੂ ਕੀਤੀਆਂ, instance size ਵਧਾ ਕੇ scale up ਕੀਤਾ, ਅਤੇ ਹੋਰ read replicas ਜੋੜ ਕੇ scale out ਕੀਤਾ. ਇਹ architecture ਲੰਮੇ ਸਮੇਂ ਤੱਕ ਸਾਡੇ ਲਈ ਬਹੁਤ ਫ਼ਾਇਦੇਮੰਦ ਰਹੀ ਹੈ. ਲਗਾਤਾਰ ਸੁਧਾਰਾਂ ਨਾਲ ਇਹ ਭਵਿੱਖੀ ਵਾਧੇ ਲਈ ਵੀ ਕਾਫ਼ੀ ਸਮਰੱਥਾ ਦਿੰਦੀ ਰਹਿੰਦੀ ਹੈ.

ਇਹ ਸੁਣਕੇ ਹੈਰਾਨੀ ਹੋ ਸਕਦੀ ਹੈ ਕਿ single-primary architecture OpenAI ਦੇ ਪੈਮਾਨੇ ਦੀਆਂ ਲੋੜਾਂ ਪੂਰੀਆਂ ਕਰ ਸਕਦੀ ਹੈ. ਪਰ ਅਸਲ ਅਮਲ ਵਿੱਚ ਇਸਨੂੰ ਚਲਾਉਣਾ ਸੌਖਾ ਨਹੀਂ ਹੈ. ਅਸੀਂ Postgres overload ਕਾਰਨ ਕਈ SEVs ਵੇਖੇ ਹਨ, ਅਤੇ ਉਹ ਅਕਸਰ ਇੱਕੋ ਪੈਟਰਨ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਨ: upstream ਸਮੱਸਿਆ ਡਾਟਾਬੇਸ ਲੋਡ ਵਿੱਚ ਅਚਾਨਕ ਉਛਾਲ ਲਿਆਉਂਦੀ ਹੈ, ਜਿਵੇਂ caching layer ਫੇਲ੍ਹ ਹੋਣ ਨਾਲ ਵਿਆਪਕ cache misses, ਮਹਿੰਗੀਆਂ multi-way joins ਦੀ ਲਹਿਰ ਨਾਲ CPU saturation, ਜਾਂ ਨਵੀਂ ਫੀਚਰ ਲਾਂਚ ਕਾਰਨ write storm. ਜਿਵੇਂ resource utilization ਵਧਦੀ ਹੈ, query latency ਵੀ ਵਧਦੀ ਹੈ ਅਤੇ requests timeout ਹੋਣ ਲੱਗਦੀਆਂ ਹਨ. ਫਿਰ retries ਲੋਡ ਨੂੰ ਹੋਰ ਵਧਾਉਂਦੀਆਂ ਹਨ, ਜਿਸ ਨਾਲ ਇੱਕ ਖ਼ਤਰਨਾਕ ਚੱਕਰ ਬਣਦਾ ਹੈ ਜੋ ਪੂਰੀ ChatGPT ਅਤੇ API ਸੇਵਾਵਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦਾ ਹੈ.

ਭਾਵੇਂ PostgreSQL ਸਾਡੇ read-heavy workloads ਲਈ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸਕੇਲ ਕਰਦਾ ਹੈ, ਫਿਰ ਵੀ ਉੱਚ write traffic ਦੇ ਦੌਰਾਨ ਸਾਨੂੰ ਚੁਣੌਤੀਆਂ ਆਉਂਦੀਆਂ ਹਨ. ਇਸ ਦਾ ਵੱਡਾ ਕਾਰਨ PostgreSQL ਦੀ multiversion concurrency control (MVCC) implementation ਹੈ, ਜੋ write-heavy workloads ਲਈ ਇਸਨੂੰ ਘੱਟ ਕੁਸ਼ਲ ਬਣਾਉਂਦੀ ਹੈ. ਉਦਾਹਰਨ ਲਈ, ਜਦੋਂ ਕੋਈ query ਇੱਕ tuple ਜਾਂ ਇੱਕੋ field ਨੂੰ update ਕਰਦੀ ਹੈ, ਤਾਂ ਨਵਾਂ version ਬਣਾਉਣ ਲਈ ਪੂਰੀ row ਦੀ copy ਬਣਦੀ ਹੈ. ਭਾਰੀ write loads ਹੇਠ ਇਸ ਨਾਲ write amplification ਕਾਫ਼ੀ ਵਧ ਜਾਂਦੀ ਹੈ. ਇਹ read amplification ਵੀ ਵਧਾਉਂਦਾ ਹੈ, ਕਿਉਂਕਿ queries ਨੂੰ ਸਭ ਤੋਂ ਨਵਾਂ version ਲੈਣ ਲਈ ਕਈ tuple versions (dead tuples) ਵਿੱਚੋਂ scan ਕਰਨਾ ਪੈਂਦਾ ਹੈ. MVCC ਹੋਰ ਚੁਣੌਤੀਆਂ ਵੀ ਲਿਆਉਂਦਾ ਹੈ, ਜਿਵੇਂ table ਅਤੇ index bloat, index maintenance overhead ਵਿੱਚ ਵਾਧਾ, ਅਤੇ autovacuum tuning ਦੀ ਜਟਿਲਤਾ. (ਇਨ੍ਹਾਂ ਮੁੱਦਿਆਂ ਬਾਰੇ ਡੂੰਘੀ ਚਰਚਾ ਲਈ ਤੁਸੀਂ ਮੇਰਾ Prof. Andy Pavlo ਨਾਲ Carnegie Mellon University ਵਿੱਚ ਲਿਖਿਆ ਬਲੌਗ The Part of PostgreSQL We Hate the Most⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) ਵੇਖ ਸਕਦੇ ਹੋ, ਜਿਸਦਾ PostgreSQL Wikipedia ਪੰਨੇ ਵਿੱਚ ਹਵਾਲਾ ਦਿੱਤਾ ਗਿਆ ਹੈ⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ).)

ਇਨ੍ਹਾਂ ਸੀਮਾਵਾਂ ਨੂੰ ਘਟਾਉਣ ਅਤੇ write pressure ਕਮ ਕਰਨ ਲਈ ਅਸੀਂ shardable, write-heavy workloads ਨੂੰ sharded systems ਜਿਵੇਂ Azure Cosmos DB ਵੱਲ migrate ਕੀਤਾ ਹੈ ਅਤੇ ਕਰ ਰਹੇ ਹਾਂ, ਨਾਲ ਹੀ application logic ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ optimize ਕੀਤਾ ਹੈ ਕਿ ਗੈਰ-ਜ਼ਰੂਰੀ writes ਘੱਟ ਤੋਂ ਘੱਟ ਹੋਣ. ਅਸੀਂ ਮੌਜੂਦਾ PostgreSQL deployment ਵਿੱਚ ਨਵੀਆਂ tables ਸ਼ਾਮਲ ਕਰਨ ਦੀ ਆਗਿਆ ਵੀ ਹੁਣ ਨਹੀਂ ਦਿੰਦੇ. ਨਵੇਂ workloads ਮੂਲ ਤੌਰ ‘ਤੇ sharded systems ‘ਤੇ ਹੀ ਜਾਂਦੇ ਹਨ.

ਭਾਵੇਂ ਸਾਡਾ infrastructure ਵਿਕਸਿਤ ਹੋਇਆ ਹੈ, PostgreSQL ਅਜੇ ਵੀ unsharded ਹੈ, ਅਤੇ ਇੱਕ ਹੀ primary instance ਸਾਰੀਆਂ writes ਸੰਭਾਲਦੀ ਹੈ. ਇਸਦਾ ਮੁੱਖ ਕਾਰਨ ਇਹ ਹੈ ਕਿ ਮੌਜੂਦਾ application workloads ਦੀ sharding ਬਹੁਤ ਜਟਿਲ ਅਤੇ ਸਮਾਂ ਲੈਣ ਵਾਲੀ ਹੋਵੇਗੀ, ਜਿਸ ਲਈ ਸੈਂਕੜਿਆਂ application endpoints ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਲੋੜੀਂਦੀਆਂ ਹੋਣਗੀਆਂ ਅਤੇ ਮਹੀਨਿਆਂ ਜਾਂ ਸਾਲਾਂ ਦਾ ਸਮਾਂ ਲੱਗ ਸਕਦਾ ਹੈ. ਕਿਉਂਕਿ ਸਾਡੇ workloads ਮੁੱਖ ਤੌਰ ‘ਤੇ read-heavy ਹਨ ਅਤੇ ਅਸੀਂ ਵਿਆਪਕ optimizations ਲਾਗੂ ਕੀਤੀਆਂ ਹਨ, ਮੌਜੂਦਾ architecture ਹਾਲੇ ਵੀ ਲਗਾਤਾਰ ਟ੍ਰੈਫਿਕ ਵਾਧੇ ਲਈ ਕਾਫ਼ੀ headroom ਦਿੰਦੀ ਹੈ. ਅਸੀਂ ਭਵਿੱਖ ਵਿੱਚ PostgreSQL ਦੀ sharding ਨੂੰ ਨਕਾਰ ਨਹੀਂ ਰਹੇ, ਪਰ ਮੌਜੂਦਾ ਅਤੇ ਆਉਣ ਵਾਲੇ ਵਾਧੇ ਲਈ ਸਾਡੇ ਕੋਲ ਕਾਫ਼ੀ runway ਹੋਣ ਕਰਕੇ ਇਹ ਨਜ਼ਦੀਕੀ ਤਰਜੀਹ ਨਹੀਂ ਹੈ.

ਅਗਲੇ ਭਾਗਾਂ ਵਿੱਚ ਅਸੀਂ ਉਹਨਾਂ ਚੁਣੌਤੀਆਂ ਅਤੇ ਵਿਆਪਕ optimizations ਦੀ ਗੱਲ ਕਰਾਂਗੇ ਜੋ ਅਸੀਂ ਲਾਗੂ ਕੀਤੀਆਂ, ਤਾਂ ਜੋ ਭਵਿੱਖੀ outages ਰੋਕੇ ਜਾ ਸਕਣ, PostgreSQL ਨੂੰ ਇਸ ਦੀਆਂ ਹੱਦਾਂ ਤੱਕ ਧੱਕਿਆ ਜਾ ਸਕੇ, ਅਤੇ ਇਸਨੂੰ ਪ੍ਰਤੀ ਸਕਿੰਟ ਲੱਖਾਂ queries (QPS) ਤੱਕ ਸਕੇਲ ਕੀਤਾ ਜਾ ਸਕੇ.

ਚੁਣੌਤੀ: ਕੇਵਲ ਇੱਕ writer ਹੋਣ ਕਾਰਨ single-primary setup writes ਨੂੰ ਸਕੇਲ ਨਹੀਂ ਕਰ ਸਕਦਾ. ਭਾਰੀ write spikes ਤੇਜ਼ੀ ਨਾਲ primary ਨੂੰ overload ਕਰ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ChatGPT ਅਤੇ ਸਾਡੀ API ਵਰਗੀਆਂ ਸੇਵਾਵਾਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦੀਆਂ ਹਨ.

ਹੱਲ: ਅਸੀਂ primary ਉੱਤੇ ਲੋਡ, ਚਾਹੇ reads ਹੋਣ ਜਾਂ writes, ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਘੱਟ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਜੋ write spikes ਨੂੰ ਸੰਭਾਲਣ ਲਈ ਇਸਦੇ ਕੋਲ ਕਾਫ਼ੀ ਸਮਰੱਥਾ ਰਹੇ. ਜਿੱਥੇ ਸੰਭਵ ਹੋਵੇ read traffic ਨੂੰ replicas ਵੱਲ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ. ਪਰ ਕੁਝ read queries ਨੂੰ primary ਉੱਤੇ ਹੀ ਰਹਿਣਾ ਪੈਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਉਹ write transactions ਦਾ ਹਿੱਸਾ ਹੁੰਦੀਆਂ ਹਨ. ਉਨ੍ਹਾਂ ਲਈ ਅਸੀਂ ਯਕੀਨੀ ਬਣਾਉਂਦੇ ਹਾਂ ਕਿ ਉਹ ਕੁਸ਼ਲ ਹੋਣ ਅਤੇ slow queries ਤੋਂ ਬਚਣ. Write traffic ਲਈ ਅਸੀਂ shardable, write-heavy workloads ਨੂੰ Azure CosmosDB ਵਰਗੇ sharded systems ਵੱਲ migrate ਕੀਤਾ ਹੈ. ਜਿਹੜੇ workloads shard ਕਰਨਾ ਔਖਾ ਹਨ ਪਰ ਫਿਰ ਵੀ ਉੱਚ write volume ਪੈਦਾ ਕਰਦੇ ਹਨ, ਉਹਨਾਂ ਦੀ migration ਵੱਧ ਸਮਾਂ ਲੈਂਦੀ ਹੈ, ਅਤੇ ਇਹ ਪ੍ਰਕਿਰਿਆ ਅਜੇ ਵੀ ਜਾਰੀ ਹੈ. ਅਸੀਂ write load ਘਟਾਉਣ ਲਈ ਆਪਣੀਆਂ applications ਨੂੰ ਵੀ ਆਗਰਸੀਵ ਤਰੀਕੇ ਨਾਲ optimize ਕੀਤਾ ਹੈ. ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ ਉਹ application bugs ਠੀਕ ਕੀਤੇ ਜਿਨ੍ਹਾਂ ਕਾਰਨ redundant writes ਹੁੰਦੀਆਂ ਸਨ, ਅਤੇ ਜਿੱਥੇ ਢੁੱਕਵਾਂ ਹੋਵੇ ਉੱਥੇ lazy writes ਲਿਆਂਦੀਆਂ, ਤਾਂ ਜੋ traffic spikes ਸਮਤਲ ਰਹਿਣ. ਇਸ ਤੋਂ ਇਲਾਵਾ, table fields backfill ਕਰਦੇ ਸਮੇਂ ਅਸੀਂ excessive write pressure ਤੋਂ ਬਚਣ ਲਈ ਕੜੀਆਂ rate limits ਲਾਗੂ ਕਰਦੇ ਹਾਂ.

ਚੁਣੌਤੀ: ਅਸੀਂ PostgreSQL ਵਿੱਚ ਕਈ ਮਹਿੰਗੀਆਂ queries ਦੀ ਪਹਿਚਾਣ ਕੀਤੀ. ਪਹਿਲਾਂ, ਇਨ੍ਹਾਂ queries ਵਿੱਚ ਅਚਾਨਕ ਵੋਲਿਊਮ spikes ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ CPU ਖਾ ਜਾਂਦੀਆਂ ਸਨ, ਜਿਸ ਨਾਲ ChatGPT ਅਤੇ API requests ਦੋਹਾਂ ਹੌਲੀਆਂ ਹੋ ਜਾਂਦੀਆਂ ਸਨ.

ਹੱਲ: ਕੁਝ ਮਹਿੰਗੀਆਂ queries, ਜਿਵੇਂ ਕਈ tables ਨੂੰ ਇਕੱਠੇ join ਕਰਨ ਵਾਲੀਆਂ, ਪੂਰੀ ਸੇਵਾ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਬਹੁਤ ਖਰਾਬ ਕਰ ਸਕਦੀਆਂ ਹਨ ਜਾਂ ਉਸਨੂੰ ਡਾਊਨ ਵੀ ਕਰ ਸਕਦੀਆਂ ਹਨ. ਸਾਨੂੰ PostgreSQL queries ਨੂੰ ਲਗਾਤਾਰ optimize ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਤਾਂ ਜੋ ਉਹ ਕੁਸ਼ਲ ਰਹਿਣ ਅਤੇ ਆਮ Online Transaction Processing (OLTP) anti-patterns ਤੋਂ ਬਚਿਆ ਜਾ ਸਕੇ. ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ ਇੱਕ ਵਾਰ ਬਹੁਤ ਹੀ ਮਹਿੰਗੀ query ਦੀ ਪਛਾਣ ਕੀਤੀ ਸੀ ਜੋ 12 tables ਨੂੰ join ਕਰਦੀ ਸੀ, ਅਤੇ ਇਸ query ਵਿੱਚ spikes ਪਿਛਲੇ high-severity SEVs ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਸਨ. ਜਿੱਥੇ ਵੀ ਸੰਭਵ ਹੋਵੇ, ਜਟਿਲ multi-table joins ਤੋਂ ਬਚਣਾ ਚਾਹੀਦਾ ਹੈ. ਜੇ joins ਲਾਜ਼ਮੀ ਹੋਣ, ਤਾਂ ਅਸੀਂ ਸਿੱਖਿਆ ਕਿ query ਨੂੰ ਤੋੜਨਾ ਅਤੇ complex join logic ਨੂੰ application layer ਵਿੱਚ ਲਿਜਾਣਾ ਵਿਚਾਰਣਾ ਚਾਹੀਦਾ ਹੈ. ਇਨ੍ਹਾਂ ਸਮੱਸਿਆਜਨਕ queries ਵਿੱਚੋਂ ਕਈ Object-Relational Mapping frameworks (ORMs) ਦੁਆਰਾ ਬਣਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਉਹਨਾਂ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤੇ SQL ਦਾ ਧਿਆਨ ਨਾਲ ਸਮੀਖਿਆ ਕਰਨਾ ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਮਹੱਤਵਪੂਰਣ ਹੈ ਕਿ ਉਹ ਉਮੀਦ ਅਨੁਸਾਰ ਵਰਤਾਓ ਕਰਦਾ ਹੈ. PostgreSQL ਵਿੱਚ ਲੰਮਾ ਸਮਾਂ idle ਰਹਿਣ ਵਾਲੀਆਂ queries ਮਿਲਣਾ ਵੀ ਆਮ ਹੈ. idle_in_transaction_session_timeout ਵਰਗੇ timeouts ਸੈੱਟ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ ਤਾਂ ਜੋ ਉਹ autovacuum ਨੂੰ block ਨਾ ਕਰਨ.

ਚੁਣੌਤੀ: ਜੇ ਕੋਈ read replica ਡਾਊਨ ਹੋ ਜਾਵੇ, ਤਾਂ ਟ੍ਰੈਫਿਕ ਨੂੰ ਹੋਰ replicas ਵੱਲ ਭੇਜਿਆ ਜਾ ਸਕਦਾ ਹੈ. ਪਰ ਇੱਕ ਹੀ writer ਉੱਤੇ ਨਿਰਭਰਤਾ ਦਾ ਮਤਲਬ ਹੈ ਇੱਕ single point of failure. ਜੇ ਉਹ ਡਾਊਨ ਹੋ ਜਾਵੇ, ਤਾਂ ਪੂਰੀ ਸੇਵਾ ਪ੍ਰਭਾਵਿਤ ਹੁੰਦੀ ਹੈ.

ਹੱਲ: ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਣ requests ਵਿੱਚ ਅਕਸਰ ਕੇਵਲ read queries ਹੁੰਦੀਆਂ ਹਨ. Primary ਵਿੱਚ single point of failure ਨੂੰ ਘਟਾਉਣ ਲਈ ਅਸੀਂ ਉਹ reads writer ਤੋਂ replicas ਵੱਲ offload ਕੀਤੀਆਂ, ਤਾਂ ਜੋ primary ਡਾਊਨ ਹੋਣ ਉੱਪਰੰਤ ਵੀ ਉਹ requests ਸੇਵਾ ਜਾਰੀ ਰੱਖ ਸਕਣ. ਭਾਵੇਂ write operations ਫਿਰ ਵੀ ਫੇਲ੍ਹ ਹੋਣਗੀਆਂ, ਪਰ ਪ੍ਰਭਾਵ ਘੱਟ ਰਹੇਗਾ. ਇਹ ਹੁਣ SEV0 ਨਹੀਂ ਰਹਿੰਦਾ ਕਿਉਂਕਿ reads ਉਪਲਬਧ ਰਹਿੰਦੀਆਂ ਹਨ.

Primary failures ਨੂੰ ਘਟਾਉਣ ਲਈ ਅਸੀਂ primary ਨੂੰ High-Availability (HA) mode ਵਿੱਚ hot standby ਨਾਲ ਚਲਾਉਂਦੇ ਹਾਂ, ਜੋ ਇੱਕ ਲਗਾਤਾਰ synchronized replica ਹੁੰਦੀ ਹੈ ਅਤੇ ਟ੍ਰੈਫਿਕ ਸੰਭਾਲਣ ਲਈ ਹਮੇਸ਼ਾਂ ਤਿਆਰ ਰਹਿੰਦੀ ਹੈ. ਜੇ primary ਡਾਊਨ ਹੋ ਜਾਵੇ ਜਾਂ maintenance ਲਈ offline ਲੈਣੀ ਪਵੇ, ਤਾਂ downtime ਘੱਟ ਕਰਨ ਲਈ ਅਸੀਂ standby ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ promote ਕਰ ਸਕਦੇ ਹਾਂ. Azure PostgreSQL ਟੀਮ ਨੇ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਵੱਡਾ ਕੰਮ ਕੀਤਾ ਹੈ ਕਿ ਬਹੁਤ ਉੱਚੇ ਲੋਡ ਹੇਠ ਵੀ ਇਹ failovers ਸੁਰੱਖਿਅਤ ਅਤੇ ਭਰੋਸੇਯੋਗ ਰਹਿਣ. Read replica failures ਨੂੰ ਸੰਭਾਲਣ ਲਈ ਅਸੀਂ ਹਰ region ਵਿੱਚ ਕਾਫ਼ੀ capacity headroom ਨਾਲ ਕਈ replicas deploy ਕਰਦੇ ਹਾਂ, ਤਾਂ ਜੋ ਇੱਕ replica ਦੇ ਫੇਲ੍ਹ ਹੋਣ ਨਾਲ ਖੇਤਰੀ outage ਨਾ ਹੋਵੇ.

ਚੁਣੌਤੀ: ਅਸੀਂ ਅਕਸਰ ਐਸੀ ਸਥਿਤੀਆਂ ਵੇਖਦੇ ਹਾਂ ਜਿੱਥੇ ਕੁਝ requests PostgreSQL instances ਉੱਤੇ ਅਣੁਪਾਤਿਕ ਤੌਰ ‘ਤੇ ਵੱਧ resources ਵਰਤ ਲੈਂਦੀਆਂ ਹਨ. ਇਸ ਨਾਲ ਉਹਨਾਂ ਹੀ instances ਉੱਤੇ ਚੱਲ ਰਹੇ ਹੋਰ workloads ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਘਟ ਸਕਦੀ ਹੈ. ਉਦਾਹਰਨ ਲਈ, ਨਵੀਂ ਫੀਚਰ ਲਾਂਚ ਅਜਿਹੀਆਂ inefficient queries ਲਿਆ ਸਕਦੀ ਹੈ ਜੋ PostgreSQL CPU ਨੂੰ ਬਹੁਤ ਵਰਤਦੀਆਂ ਹਨ ਅਤੇ ਹੋਰ ਮਹੱਤਵਪੂਰਣ ਫੀਚਰਾਂ ਲਈ requests ਨੂੰ ਹੌਲਾ ਕਰ ਦਿੰਦੀਆਂ ਹਨ.

Solution: To mitigate the “noisy neighbor” problem, we isolate workloads onto dedicated instances to ensure that sudden spikes in resource-intensive requests don’t impact other traffic. Specifically, we split requests into low-priority and high-priority tiers and route them to separate instances. This way, even if a low-priority workload becomes resource-intensive, it won’t degrade the performance of high-priority requests. We apply the same strategy across different products and services as well, so that activity from one product does not affect the performance or reliability of another.

Challenge: Each instance has a maximum connection limit (5,000 in Azure PostgreSQL). It’s easy to run out of connections or accumulate too many idle ones. We’ve previously had incidents caused by connection storms that exhausted all available connections.

Solution: We deployed PgBouncer as a proxy layer to pool database connections. Running it in statement or transaction pooling mode allows us to efficiently reuse connections, greatly reducing the number of active client connections. This also cuts connection setup latency: in our benchmarks, the average connection time dropped from 50 milliseconds (ms) to 5 ms. Inter-region connections and requests can be expensive, so we co-locate the proxy, clients, and replicas in the same region to minimize network overhead and connection use time. Moreover, PgBouncer must be configured carefully. Settings like idle timeouts are critical to prevent connection exhaustion.

Challenge: A sudden spike in cache misses can trigger a surge of reads on the PostgreSQL database, saturating CPU and slowing user requests.

Solution: To reduce read pressure on PostgreSQL, we use a caching layer to serve most of the read traffic. However, when cache hit rates drop unexpectedly, the burst of cache misses can push a large volume of requests directly to PostgreSQL. This sudden increase in database reads consumes significant resources, slowing down the service. To prevent overload during cache-miss storms, we implement a cache locking (and leasing) mechanism so that only a single reader that misses on a particular key fetches the data from PostgreSQL. When multiple requests miss on the same cache key, only one request acquires the lock and proceeds to retrieve the data and repopulate the cache. All other requests wait for the cache to be updated rather than all hitting PostgreSQL at once. This significantly reduces redundant database reads and protects the system from cascading load spikes.

Challenge: The primary streams Write Ahead Log (WAL) data to every read replica. As the number of replicas increases, the primary must ship WAL to more instances, increasing pressure on both network bandwidth and CPU. This causes higher and more unstable replica lag, which makes the system harder to scale reliably.

Solution: We operate nearly 50 read replicas across multiple geographic regions to minimize latency. However, with the current architecture, the primary must stream WAL to every replica. Although it currently scales well with very large instance types and high-network bandwidth, we can’t keep adding replicas indefinitely without eventually overloading the primary. To address this, we’re collaborating with the Azure PostgreSQL team on cascading replication⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ), where intermediate replicas relay WAL to downstream replicas. This approach allows us to scale to potentially over a hundred replicas without overwhelming the primary. However, it also introduces additional operational complexity, particularly around failover management. The feature is still in testing; we’ll ensure it’s robust and can fail over safely before rolling it out to production.

Challenge: A sudden traffic spike on specific endpoints, a surge of expensive queries, or a retry storm can quickly exhaust critical resources such as CPU, I/O, and connections, which causes widespread service degradation.

Solution: We implemented rate-limiting across multiple layers—application, connection pooler, proxy, and query—to prevent sudden traffic spikes from overwhelming database instances and triggering cascading failures. It’s also crucial to avoid overly short retry intervals, which can trigger retry storms. We also enhanced the ORM layer to support rate limiting and when necessary, fully block specific query digests. This targeted form of load shedding enables rapid recovery from sudden surges of expensive queries.

Challenge: Even a small schema change, such as altering a column type, can trigger a full table rewrite⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ). We therefore apply schema changes cautiously—limiting them to lightweight operations and avoiding any that rewrite entire tables.

Solution: Only lightweight schema changes are permitted, such as adding or removing certain columns that do not trigger a full table rewrite. We enforce a strict 5-second timeout on schema changes. Creating and dropping indexes concurrently is allowed. Schema changes are restricted to existing tables. If a new feature requires additional tables, they must be in alternative sharded systems such as Azure CosmosDB rather than PostgreSQL. When backfilling a table field, we apply strict rate limits to prevent write spikes. Although this process can sometimes take over a week, it ensures stability and avoids any production impact.

This effort demonstrates that with the right design and optimizations, Azure PostgreSQL can be scaled to handle the largest production workloads. PostgreSQL handles millions of QPS for read-heavy workloads, powering OpenAI’s most critical products like ChatGPT and the API platform. We added nearly 50 read replicas, while keeping replication lag near zero, maintained low-latency reads across geo-distributed regions, and built sufficient capacity headroom to support future growth.

This scaling works while still minimizing latency and improving reliability. We consistently deliver low double-digit millisecond p99 client-side latency and five-nines availability in production. And over the past 12 months, we’ve had only one SEV-0 PostgreSQL incident (it occurred during the viral launch⁠(ਨਵੀਂ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ) of ChatGPT ImageGen, when write traffic suddenly surged by more than 10x as over 100 million new users signed up within a week.)

While we’re happy with how far PostgreSQL has taken us, we continue to push its limits to ensure we have sufficient runway for future growth. We’ve already migrated the shardable write-heavy workloads to our sharded systems like CosmosDB. The remaining write-heavy workloads are more challenging to shard—we’re actively migrating those as well to further offload writes from the PostgreSQL primary. We’re also working with Azure to enable cascading replication so we can safely scale to significantly more read replicas.

Looking ahead, we’ll continue to explore additional approaches to further scale, including sharded PostgreSQL or alternative distributed systems, as our infrastructure demands continue to grow.