昨天看到 Supabase， 它的 slogan 是 Give Your Database Superpowers 感覺蠻厲害的，裝了一下：有 Self-hosting docker 版本。 它目的是幾乎模仿firebase 的功能， 但是是以 postgreSQL 為核心，並在上層作封裝。
特色 open source 封裝 postgreSQL 有 platform 和 Self-hosting(Docker) 兩種版本，其中 Self-hosting 是完全免費 Realtime PostgREST 用 Kong 當 API Gateway Storage 目前支援 S3 相當強悍的 Authentication / Authorization 一次跑 8 個 container 如下
⠿ Container supabase-kong Stopped 2.9s ⠿ Container supabase-studio Stopped 2.7s ⠿ Container supabase-storage Stopped 10.8s ⠿ Container supabase-auth Stopped 0....
議題討論: 因為想把產品做 scale out 所以要用 NoSQL 取代 產品中原有的 PostgreSQL， 畢竟 RDBMS 本來就沒有 Native multi-master 的支援 !?
前提 下文感想的前提是如果技術團隊中目前沒有 NoSQL 的高手存在，但想要將 已上市的產品立即切換成任一種 NoSQL 的情境。
不包含團隊中本來就有多位 noSQL 高手的情境
NoSQL 我自己使用過 Firebase/FireStore/DataStore/MongoDB，僅是感想紀錄
先講結論 採用 NoSQL 的時間點 ? 當團隊中本來就有 NoSQL 高手 (或) 當團隊中同時有多位熟悉(多年經驗)特定 NoSQL 的 developer (或) 當團隊想開發公司/部門裡的軟體，使用自己生產的軟體(Eating your own dog food)，藉以累積實戰經驗 (或) 新創團隊，產品尚未有使用者，離上市還很遠 (或) 這是趨勢 ! 不管就是只想用 Cloud Service 上現成的或 BAAS 除了以上5點之外，建議沿用 PostgreSQL，把最新版的 pgSQL 的特性發揮應可應付絕大部分的場景。雖然 NoSQL 要設定 Scalability 的確容易得多(原生的)，但如果會產生更多不方便的地方(如下)，那何必強求容易設定 Scale-Out 這一個優點 ?...