先定義一筆資料再估容量
準備歷史資料庫時，先算一天會保存多少筆，再乘上每筆實際占用空間。不要拿感測器的四位元組數值直接乘點數，就把結果當成硬碟需求；時間、品質、點位識別、資料列與索引都可能占空間。本文帶你建立可重算的估算表，再用試存結果校正。
先寫下五個條件：點數、每點保存頻率、保存天數、一筆資料的範圍，以及容量單位。本文假設一百個點各自存成一列，每秒保存一次，連續運作三百六十五天。若你的資料表是一列含一百個欄位，必須重新測每列大小，不能直接套用每點一列的模型。
把採集頻率與落盤頻率分開。PLC每十毫秒更新，不代表歷史庫每十毫秒插入；資料變化才儲存的系統也不等於固定週期儲存。先查歷史設定、最長保存間隔、死區與品質變化是否另產生記錄，再決定筆數模型。
本文容量以十進位表示：一GB是一十億bytes；一GiB是二的三十次方bytes。把兩者混用會讓規劃表與作業系統顯示看起來不同。報告保留原始bytes，再另外換算，不要只抄畫面上四捨五入後的數字。
適用於一般工業歷史庫的容量規劃；資料列壓縮、分區與索引方式依產品而異。後段以PostgreSQL 18公開函式說明量測範圍，不代表其他歷史庫具有相同函式或儲存成本。
跟著算一百個點一年的資料量
每天秒數為二十四乘六十乘六十，得到86400秒。每秒一百筆，所以每天8640000筆，一年3153600000筆。先檢查這個數量是否符合現場需要；取樣週期若改五秒，在其他條件相同時，筆數就是五分之一。
假設僅供估算的一筆有效資料內容為二十四bytes，則每日資料內容207360000bytes，也就是0.20736GB；一年75.6864GB。這裡的二十四bytes不是PostgreSQL固定列大小，也不是廠商保證值，尚未含索引、資料列額外空間或備份。
另做一個試存校正情境：代表性測試期間共新增一千萬筆，而資料表連同索引占用空間增加六億bytes。其平均增量為六十bytes每筆。用這個量測假設估算，全年約189.216GB。它已含測量範圍內的索引，不能再把同一索引加一次。
為便於覆核，試算表依序保留輸入值、每日筆數、年度筆數、每筆成本及年度空間。每個輸入另加「設定值」「試存量測」或「保守假設」欄。只要保存週期改變，就能追到哪些結果必須重算。
完成後應看到兩個不同層次的數字：七十五點六八六四GB是本例有效內容估算；一百八十九點二一六GB是本例試存平均成本推估。不能把兩者相加，因為後者已包含前者所代表的資料。
把壓縮與變化儲存分開試算
若只在變化時儲存，先以代表性資料估計實際保留筆數比例。假設固定週期模型中有百分之二十的筆數留下，在每筆成本不變的簡化條件下，一年約37.8432GB。這是筆數減少，不是壓縮率；品質改變或強制定時保存也必須算入留下的筆數。
壓縮是另一個層次。若同一範圍的未壓縮內容是一百GB，壓縮後六十GB，本文稱保留比例百分之六十、節省百分之四十。不要只寫「壓縮率六十」而讓讀者猜意思，更不要把原本已經壓縮的實測空間再乘一次。
試算至少保留正常生產、頻繁切換與通訊異常三種情境。平穩溫度可能很少變，警報風暴或品質抖動卻可能大量新增。選擇測試期間時應涵蓋開機、停機、換線與補送，而不是只拿安靜的十分鐘。
長期保存也不一定線性：分區建立可能預先占空間，索引會成長，刪除的空間可能留待重用。先把線性公式作為第一版預算，再以週與月的占用變化修正。若設定自動淘汰，還要驗證淘汰是否按期成功。
失敗時先查實際插入筆數，再查平均每筆大小。筆數超標常見原因是重複寫入、重送未去重或死區未生效；每筆成本上升則查新增索引、字串長度、品質欄與資料表空間回收狀況。
量測空間與預留維運容量
在PostgreSQL中，pg_total_relation_size包含指定表的索引與TOAST等空間；pg_table_size不含該表索引，pg_indexes_size量測其索引。選定相同範圍，在試存前後記錄原始bytes與資料筆數，才能得到有意義的增量。分區表應盤點實際子表，不能只量父表就當全部。
整個資料庫的量測也不等於整台主機的磁碟需求。交易日誌、備份、暫存檔、作業系統及其他資料庫分開列帳；量測資料表總量之後，不要又把整個資料庫量測加上去造成重複。備份檔案應用實際格式與保留份數測量。
延續年度189.216GB的情境，另假設備份120GB、日誌與暫存尖峰30GB，合計339.216GB。若目標是這些項目最多占可用配置容量百分之七十，配置量須為339.216除以0.7，約484.60GB。保留百分之三十空間與直接乘1.3不是同一意思。
這個配置數字仍不是硬碟採購結論。儲存複寫、檔案系統保留、成長率與備份位置要按實際架構另列。也要測連續寫入及常用報表延遲；容量足夠卻無法在要求時間內查詢，仍未完成驗收。
交付估算表時附上採集與保存設定、測試起訖、新增筆數、空間查詢範圍與備份策略。這些證據讓接手人知道為什麼用了六十bytes，而不是只看到一個無法追溯的年度總量。
練習與常見問題
練習：將本例固定保存週期改成五秒，其餘維持一百點、三百六十五天、六十bytes每筆。應算出每天1728000筆，年度630720000筆，資料表與索引推估37.8432GB。這個數字恰與前面的百分之二十變化儲存案例相同，但兩者保留的時間資訊不相同。
驗收時選一段已知沒有斷線的短期間核對筆數，再納入中斷補送與尖峰資料。若資料庫筆數與接收數不合，先排除邊界時間、重複資料與失敗交易，再談壓縮效果；空間較小可能是漏記，不能直接當優化成功。
問：四位元組浮點數是否一筆只占四bytes？答：那只描述數值欄本體，時間、品質、識別及資料庫結構仍須計入。
問：已量表加索引，還要再乘索引係數嗎？答：不需要，除非新增了量測時尚未存在的索引，且另有明確估算。
問：能保證變化儲存節省八成嗎？答：不能。本例百分之二十只是情境假設，必須用自己的正常與尖峰資料測定。
問：保存一年後空間一定停止增加嗎？答：不一定。先驗證淘汰、空間重用、備份保留與日誌回收是否正常，再看穩態占用。本文只完成公式與文件核對，未測量現場資料庫。
參考：PostgreSQL 18 Database Object Size Functions：資料表、索引與資料庫空間的量測範圍。