從筆電連上遠端資料庫：一套心智模型

簡述

• 情境
  • 公司裡各種服務分別用到 Postgres、ClickHouse、Spark、MongoDB 當資料來源，常常需要跨這些服務直接下 query 快速撈資料。平常靠 DBeaver 這類 GUI 工具連線查看。
  • 但這一兩年 CLI 工具愈用愈順手（k9s、lazygit、lazydocker…），就開始想：能不能不要跳出去另開一個 app，直接在 terminal 一個 session 裡把結果查出來，愈快愈好？

• 動機

  • 遠端 DB 幾乎都躲在 VPC 或 GKE 裡，不開放公網直連，中間一定要隔一層 tunnel 把它「借」到本地一個 port。這條路我一直是拼湊著用，每次 flag 都要重猜——缺的是一套心智模型。
  • 所以想從頭把「筆電 → 遠端 DB」這條路一層一層拆清楚，之後不管換哪套 DB CLI 都能直接套。

• 最終目標

  • 建立一條完整的連線心智模型：先弄懂連線本身是什麼、再打通道、再看通道怎麼被打包、最後連上去查。
  • 換任何一套資料庫的 CLI，都只是同一個模型換個拼法而已。

為什麼中間要多一層 tunnel 遠端 DB 通常不對公網開放（在 VPC 或 GKE 內）。所以先用 Cloud SQL Proxy 或 kubectl port-forward 把它對映到 127.0.0.1:PORT，你的 client 之後就當成「本地 DB」在連。通道對 client 是透明的，它以為自己連的是 localhost。

這趟學習事先定義的 Roadmap

1. 先懂連線的本質：五個座標。任何 DB 連線都是 host / port / user / password / database 這五塊，URI 只是把它們串成一行。→ 一條連線就是五個座標、連線 URI 是標準式
2. 打通道：讓本地 port 連到遠端 DB。managed Cloud SQL 走 Auth Proxy，跑在 k8s 裡的 DB 走 kubectl port-forward，兩條 auth 路徑、同一個 127.0.0.1:PORT 結果。→ 兩種通道：Cloud SQL Proxy vs port-forward
3. 通道怎麼被打包：這些代理工具跑在 docker-compose 服務裡，映像從哪來、檔案怎麼進容器，決定了到底跑的是什麼。→ docker 打包：image vs build、COPY 烤進映像、volume 即時掛載
4. 連上之後就是查詢。連好之後唯一的分岔，是你有沒有丟一個 query flag：有就是一次性、沒有就進 REPL。→ 一次性查詢 vs 互動 REPL
5. 最後跑一個完整實例，MySQL 走代理，把上面全部串起來跑一次。→ MySQL 遠端連線與參數、MySQL 內嵌 SQL 的四種餵法

串起來的主軸： 五座標／URI 指定要連的 DB → tunnel 把遠端 DB 借到 localhost:PORT → docker 打包那個 tunnel → 連上後 query flag 決定一次性 or REPL → MySQL 卡片把它跑成一條完整範例。

結尾

一路學到最後，注意到一個很煩的限制：每套資料庫都有自己的 CLI，概念一模一樣，只有 flag 的拼法不同。既然概念相同，那我能不能包一個 wrapper TUI，一樣在 terminal session 裡快速跑？答案是可以——最後挑的是 sqlit，一個走「lazy」路線、跟我已經在用的 k9s／lazygit 同調的 TUI。目前正把工作流從 DBeaver 搬到 sqlit，到現在為止很順。這個收穫的完整版、附上各資料庫工具的前後對照，寫在這裡：sqlit：純鍵盤版的 DBeaver。

---

參考來源

• PostgreSQL libpq connection — https://www.postgresql.org/docs/current/libpq-connect.html
• Cloud SQL Auth Proxy — https://cloud.google.com/sql/docs/postgres/sql-proxy
• Docker Compose build reference — https://docs.docker.com/reference/compose-file/build/
• MySQL command-line client — https://dev.mysql.com/doc/refman/8.0/en/connecting.html
• sqlit — https://github.com/Maxteabag/sqlit