Gitlab की Postgres schema डिज़ाइन पर मेरे नोट्स (2022)

मूल लेख ↗ Hacker News चर्चा ↗

GitLab की PostgreSQL schema choices आधुनिक apps के बड़े पैमाने पर data modeling के तरीकों पर व्यापक आलोचना को जन्म देती हैं। Commenters 32‑bit और 64‑bit primary keys, UUIDs बनाम sequential IDs, और online schema migration की रणनीतियों के बीच trade-offs पर विचार करते हैं, यह दिखाते हुए कि index locality, foreign keys, और ORM abstractions billion-row tables पर performance को बना या बिगाड़ सकते हैं। यह चर्चा primary keys को users से छिपाने जैसी आम “best practices” पर भी सवाल उठाती है, यह तर्क देते हुए कि ये अक्सर security से अधिक business और competitive concerns से प्रेरित होती हैं, और यह जोर देती है कि tooling advances के बावजूद careful, database-first schema design अब भी महत्वपूर्ण है।

Primary key size, migrations, and tooling

  • कई टिप्पणियाँ int बनाम bigint PKs पर बहस करती हैं। कुछ का कहना है कि बड़े services के लिए 32‑bit limits तक पहुँचने का जोखिम वास्तविक है और यह “comfort के लिए बहुत करीब” है, जबकि अन्य बताते हैं कि वास्तविक डेटा (जैसे GitHub repos/issues) अभी भी 2^31 से नीचे है।
  • int→bigint migration को बड़े पैमाने पर संभव लेकिन गैर‑तुच्छ बताया गया है: table rewrites, index rebuilds, foreign keys, और single‑threaded index creation multi‑TB tables पर घंटों ले सकते हैं।
  • zero‑/low‑downtime approaches जिनका उल्लेख हुआ: logical replication with switchover, online schema change tools (pg-osc, gh-ost), schema migrations को app deploys से decouple करना, और DBA‑run migration systems।
  • कुछ लोग secondary pain points भी बताते हैं: JavaScript bigint deserialization, downstream consumers का 32‑bit ints मान लेना।

UUIDs vs sequential integers

  • UUIDv4 को PK के रूप में मुख्यतः performance के लिए आलोचना मिली, size के लिए नहीं। हर FK/index entry पर अतिरिक्त 8 bytes कई tables में जुड़कर बढ़ते जाते हैं और indexes को RAM में fit करना कठिन बनाते हैं।
  • Random UUIDs index locality को नष्ट करते हैं: btree inserts बिखर जाते हैं, page bloat पैदा करते हैं, और जब indexes memory से बड़े हो जाते हैं तो steady ~25% hit नहीं बल्कि गंभीर performance cliffs आते हैं।
  • Time‑ordered IDs (UUIDv6/v7, Snowflake‑style, encrypted or permuted sequences) को बेहतर compromise के रूप में चर्चा की गई, लेकिन इनके trade‑offs हैं (time leakage, key rotation, complexity)।

Schema design, ORMs, and migrations

  • कई लोगों का तर्क है कि schema design “stone age” है और migration tools (EF, Rails, Django, Prisma, etc.) या तो खतरनाक migrations बनाते हैं (locks, rewrites) या यह अस्पष्ट कर देते हैं कि वास्तव में क्या चल रहा है।
  • schema‑first thinking और plain SQL (अक्सर stored procedures के साथ) के पक्ष में मजबूत रुझान है, heavy ORMs की तुलना में, जिन्हें leaky, complex, और scale पर operate करने में कठिन माना जाता है।
  • अन्य लोग ORMs का बचाव करते हैं, खासकर dynamic queries और complex object graphs के लिए, यदि उन्हें समझदारी से उपयोग किया जाए।

GitLab vs GitHub architecture and performance

  • कुछ लोगों को GitLab pages, GitHub की तुलना में, noticeably slower लगती हैं। इसके लिए performance की culture और prioritization जैसी व्याख्याएँ दी गईं, लेकिन विवरण anecdotal और अधूरे हैं।
  • GitLab.com एक single multi-tenant DB है या DB-per-customer, इस पर असहमति/अनिश्चितता है; एक टिप्पणी के अनुसार यह मूलतः उनके self-hosted product का multitenant instance है।

Exposing primary keys and “external IDs”

  • एक पक्ष sequential PKs को छिपाने को मुख्यतः “security theater” मानता है; अगर authz टूट गया है, तो guessed IDs का महत्व नहीं होना चाहिए।
  • अन्य लोग defense in depth और competitive intelligence पर जोर देते हैं: sequential IDs counts/growth (orders, users, issues) उजागर करते हैं और mass enumeration तथा exploitation को आसान बनाते हैं।
  • उदाहरणों में e‑commerce order volumes, user enumeration, और scraping शामिल हैं; counter-arguments का कहना है कि motivated attackers अक्सर similar data का अंदाज़ा फिर भी लगा सकते हैं।
  • GitLab‑style internal id plus per‑project iid को user‑friendly माना गया है और यह URLs को internal PK changes से अलग करता है, हालांकि इसकी कीमत extra joins और indexes के रूप में चुकानी पड़ती है।

Postgres specifics: text vs varchar, FKs

  • चर्चा स्पष्ट करती है कि Postgres में text vs varchar(n) के बीच runtime performance difference नहीं है; असली मुद्दा migration cost है जब varchar(n) की lengths बदलनी हों बनाम text पर CHECK समायोजित करना।
  • एक commenter इस विचार का विरोध करता है कि foreign keys “expensive” हैं, और तर्क देता है कि integrity कहीं न कहीं enforce करनी ही होगी, तथा ठीक से उपयोग करने पर DB‑level FKs आमतौर पर बेहतर होते हैं।