我們最近完成了一次重大的後端遷移：將我們主要的生產資料庫從Heroku Postgres 遷移到Neon 。
這項舉措並非為了追逐耀眼的新技術或追逐下一個熱門話題。而是為了解放我們自己，獲得更好的開發者體驗、更順暢的擴展和更易於管理的成本。 Postgres 仍然是 DEV 和 Forem 的支柱，但 Neon 為我們提供了更靈活、更現代化的運作時，並為未來的發展奠定了基礎。
如今，我們已經完成了遷移，並開始反思這項措施。現在，我們受益於更低的成本、更緊密的回饋循環以及更大的成長空間。
我們為何搬家
首先，Heroku Postgres 為我們提供了良好的服務。它幫助我們快速啟動並執行，並從八年多前不起眼的起步階段到如今每月服務數百萬開發者的應用程式，一直是我們可靠的核心。但是，隨著時間的推移，我們遇到了一些持續存在的摩擦點：
-
如果不進行繁重的工作，就很難運作類似生產的環境。
-
讀取副本的使用受到限制，有時還很挑剔。
-
傳統資料庫的資源分配僵化，導致擴展效率低。
-
我們幾乎無法控制資源如何分配或計費。
-
我們預計將繼續發展並使用多個資料庫，而自動擴展功能將改變遊戲規則。
Postgres 一直以來都是我們最大的單一資源支出——遠遠超過了我們的計算和其他基礎設施成本。它也極為關鍵，我們不會只考慮降低成本，而不去尋找升級和改進的方法。核心資料庫太重要了，絕對不能考慮在它上面省錢。
因此，在考慮搜尋時，我們不僅優先考慮成本效益，還優先考慮幫助我們盡可能處理和保護資料的工具。
我們研究了眾多方案，並與多家潛在合作夥伴進行了溝通，最終確定 Neon 為最佳選擇。我們聯繫了他們的團隊，並很高興與他們建立了合作關係，最終在 DEV 上獲得了💎️鑽石贊助，並為我們的 DEV++ 會員提供了更優惠的優惠。
更好的開發循環
最大的勝利之一就是開發人員的體驗。
Neon 的分支系統讓我們能夠立即啟動獨立的資料庫環境。這意味著：
-
我們可以處理真實資料而不必擔心衝突。
-
我們可以在真實的生產環境中測試遷移、模式變更或邊緣情況。
-
我們可以確保涉及資料庫的功能預覽實際上是可行的，並且不會出現階段瓶頸。
我們也更多地使用了唯讀副本，這在過去我們不得不謹慎處理。 Neon 讓這一切變得簡單得多。無論是為了卸載長時間執行的查詢、支援自動化工具，或是嘗試特定功能的讀取路徑，啟動副本都不再昂貴或複雜。
這為處理負載開闢了新的選擇，並為我們提供了更具未來性的實驗途徑。
更智慧的擴展，更低的成本
Neon 的架構將儲存和運算分開。我們無需將所有資源同時擴展，這一直是 Heroku Postgres 固定大小產品的痛點。現在，我們可以獨立調整儲存和運算需求，只需為實際使用的部分付費。
成本方面的影響非常顯著。透過切換到 Neon，我們節省了一大筆資料庫費用。
靈活應對未來
我們非常欣賞 PostgreSQL 擴充功能和現代工具的簡潔性和可存取性，儘管我們還沒有使用過。這不僅關乎我們今天的需求，也關乎我們未來能夠多麼輕鬆地整合新的強大功能。例如， pgvector的原生支援讓我們可以輕鬆使用語意搜尋和推薦等人工智慧功能。我們也熱衷於探索pg_search ，以便在資料庫中直接實現更高級的全文搜尋功能，從而簡化我們的堆疊。除了搜尋之外，圍繞 API 和身份驗證的生態系統工具也是一個巨大的吸引力。能夠利用 Neon Data API 等工具快速建立和公開資料端點，再加上強大的身份驗證擴展，意味著我們可以比以往更快地建立和保護新服務。對我們來說，選擇 Neon 是為了讓我們的平檯面向未來，並使創新更容易實現。
遷移
將資料庫從 Heroku 遷移到 Neon 是一項艱鉅的任務，而我們在整個過程中的首要任務是確保零資料遺失和最大程度地減少停機時間。為了實現這一目標，我們使用了一款名為 Bucardo 的工具進行遷移，它使我們能夠在幾乎零停機的情況下完成資料遷移。
Bucardo 是 PostgreSQL 的一個非同步複製系統。它的工作原理是在主資料庫上建立觸發器來監視變更。然後，這些變更會被收集並在目標資料庫上重播，從而保持與來源資料庫的同步。為了管理此流程，我們與 Neon 團隊密切合作，在獨立的 DigitalOcean Droplet 上部署了 Bucardo。這使得它能夠連接到我們的 Heroku 資料庫和新的 Neon 資料庫，並在不影響主應用程式效能的情況下進行複製。
雖然 Bucardo 被證明是無縫過渡的正確選擇，但它並非完美無缺。整個過程有時有點棘手。快樂路徑總是有效，但由於遺留的觸發因素導致問題，我們不得不在某個時刻重新啟動整個過程。
我們高度關注資料完整性也意味著我們沒有完全預料到之後需要進行的配置調整。
我們使用 Heroku 已經很久了，它的資料庫配置對我們來說已經習以為常——包括一些我們習以為常的預設設定。我們只是希望資料庫在所有設定下都能以特定的方式運作。這意味著在遷移到 Neon 之後，我們必須對設定進行微調，尤其是在連接池和逾時方面，以確保一切運作最佳。我們花了幾天時間進行調整，將效能提升到 100%，但我們最終做到了。
總的來說，遷移到 Neon 取得了巨大的成功。我們實現了遷移的主要目標，即在不造成任何停機或資料遺失的情況下完成遷移。現在，我們擁有一個擁有新功能的平台，並且非常期待使用。我們仍然能夠獲得我們珍惜的開發者體驗（作為由 Heroku 託管的應用程式），同時擁有更靈活和強大的底層基礎架構。
下一步
我們已經開始將更多 Neon 功能整合到我們的工作流程中：
-
分支即功能預覽服務
-
副本支持的實驗，不影響生產
-
開發人員環境和生產資料之間的更清晰的分離
雖然您不需要 Neon 來執行 Forem（Postgres 仍然是預設值），但我們認為這種設定代表了嚴肅的應用程式將越來越依賴的一種現代基礎。
最後的想法
我們一直在尋找能夠給予我們優勢而又不束縛我們的工具。 Neon 為我們提供了更好的 Postgres，它具有更少的權衡和更大的移動空間。
我們很高興我們做出了這一跨越。
原文出處：https://dev.to/devteam/evolving-our-infrastructure-why-we-moved-from-heroku-postgres-to-neon-1928
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式