今天「My notes on Gitlab's Postgres schema design (2022) (shekhargulati.com)」這篇上 Hacker News 首頁 (看起來因為是在 pool 的關係，在第一頁卡很久...)，文章「My Notes on GitLab Postgres Schema Design」是作者在 2022 年七月的時候分析了 GitLab 的 structure.sql 的資料庫設計整理出來的心得 & 感想，裡面有不少東西，不過這邊想補充個背景知識 (姿勢？)：
RDBMS 在系統架構裡面，相較於其他的元件，是個很難 scale out 的東西 (i.e. 加更多機器得到更多效能)，所以遇過 scalability 問題的架構師，會很習慣避開在 RDBMS 上面跑各種功能，有其他方式可以做的就拆出去用容易 scale out 的工具來做，非不得已才上 RDBMS。
而就算要塞進 RDBMS 裡的資料，能省的還是要省，畢竟宣稱自動幫你處理資料庫 scale out 的技術 (像是 CockroachDB 與 TiDB) 其實沒想像中萬能，還是需要開發者改寫以前大惡搞的 SQL query (一個 terminal 列不完那種)。
而你心裡也有底，如果 scale out 不是條好的路，那麼只好 scale up (i.e. 加大機器的 CPU & RAM)，而 scale up 總是有極限，真的遇到自己被迫要處理 sharding 的時候，DBOps/DBA 與 Dev 的臉都很臭... (一堆 JOIN 要改成拉回 application 端自己湊，或是有 ProxySQL 這種東西幫你處理，但是發現 ProxySQL 去後面資料庫拉太多資料幫你組反而很慢 !@#$%)
但另外一方面，現在已經不是 2005 年 64GB RAM 的伺服器是個天價的年代... 硬體的成長已經長到在 AWS 雲端上面可以租到給 SAP 用的 24TB RAM 的機器 (u-24tb1.112xlarge)，而地端找個 server 也都有 15TB RAM (POWEREDGE R940)，所以很容易把所有資料都塞到記憶體裡面搞，加上 NVMe 的讀寫速度比以前 HDD disk 快多了。
記得這兩件都是現實，然後再回來看文章內容與其他的討論，用不同的現實就會有不同的想法出現。
GitLab 的設計有他當時的限制以及想法，這些是外面的人看不到的，也就不好批評對錯。
