一個應用系統隨着業務量的提高,以及訪問量和數據流量的快速增長，各個核心部分的處理性能和計算強度也相應增大，使得單一設備根本無法承擔。在此情況下，如果扔掉現有設備去做大量的硬件升級，必將造成現有資源的浪費，而且下一次業務量的提升，又將導致再一次硬件升級的高額成本投入。於是，負載均衡機制應運而生。
對於應用系統的負載均衡的硬件和軟件比比皆是，因爲應用服務器上的程序基本上認爲是不變化的，而且一般的各個應用服務器上的程序是不交互的。因此應用服務器的負載均衡非常好做，只需要能夠進行分流的軟件或者硬件把多個客戶端的連接分配到多個應用服務器上去即可。
因爲數據庫內的數據是頻繁變化的，爲了數據的一致性以及鎖資源的分配協調等，所以像應用服務器那樣只有分流是不夠的，各個節點需要頻繁的交互。這也是數據庫集羣軟件難做的原因，當然也是賣的貴的原因了。
對於數據庫負載均衡，大家最爲耳熟能詳的就是Oracle RAC了。RAC是雙機並行服務器(8i及以前版本稱作Oracle Parallel Server，OPS)，用來在集羣環境下實現多機共享數據庫，以保證應用的高可用性，同時可以自動實現並行處理及均分負載，還能實現數據庫在故障時的排錯和無斷點恢復。它可以自動進行負載平衡、故障修復和規劃停機時間，以支持高可用性應用程序。若並行服務器中某節點失效，透明的應用程序容錯能夠把用戶自動轉接到另一節點上繼續運行，應用程序在用戶沒有察覺的情況下繼續執行。這使週期性和非週期性發生故障的系統增大了連續可用性。進程的失效可以完全透明地轉移到另一節點上去，通過適當地配置，可以指定所有查詢都在客戶端進行緩存，這樣它們便可以在轉移後的節點上重新設置。
截至到SQL Server 2008，微軟還是沒有推出負載均衡組件，只能靠第三方軟件來實現，好在這個軟件是幾個從微軟出來的人寫的，也算是個小小的巧合。說他們是微軟出來的並不是說他們的技術多厲害，而是他們利用SQL Server的一些內部接口把集羣做的非常透明， 無論是應用程序的調用還是開發/管理人員的使用都和麪對一個數據庫一樣。
他們的實現原理是這樣的：和SQL Server鏡像一樣，每個數據庫節點都有自己的數據，也就是無共享磁盤架構。他們稱之爲“中間件”的程序宿主在數據庫的內部，每個節點數據庫上寫入數據導致數據變化時，SQL Server會激活“中間件”，“中間件”把變化的數據同步到其他的節點上。其他節點發生變化也是一樣。因爲“中間件”宿主在數據庫內， 所以它能夠把每個同步的Session和SQL Server的Session綁定到一起，也就是使用戶的執行和數據的同步成爲一個原子操作，從而保證數據在每時每刻都是一致的。因此查詢可以隨便到每個機器上去查，從而做到了真正的負載均衡。