這是歷史版本頁面 — 看 PostgreSQL 最新版本
資料庫卡卡或鎖死?PostgreSQL 能解決什麼
你正在開發一個網站或應用程式,資料量從幾千筆成長到幾十萬筆,原本順暢的查詢開始變慢,甚至偶爾出現「資料庫被鎖住」的錯誤。你想找一個能撐住這種成長、又不會讓你在資料正確性上提心吊膽的資料庫,但市面上選項太多,不知道從哪裡下手。
一般人習慣先用 Excel 或輕量型資料庫(例如 SQLite)撐著,但資料一多、同時讀寫的人一多,這些方案就會開始出現效能瓶頸或鎖定問題。這類工具真正的切入點,是提供一套完整的「關聯式資料庫管理系統」:用結構化的表格存放資料、用 SQL 查詢、支援交易(Transaction)確保資料不會寫到一半出錯,並透過索引、分割區等機制讓查詢在資料量變大時仍然有辦法維持效能。
01PostgreSQL 這套軟體到底能做什麼?
它是一套開放原始碼的關聯式資料庫管理系統,主要用途是存放、查詢、管理結構化資料。你可以用它建立多張有關聯的表格,用 SQL 語法做新增、讀取、更新、刪除,並設定主鍵、外鍵、唯一性限制等規則來確保資料正確。它也支援交易、並行控制、備份還原,適合當作網站、應用程式或內部系統的資料後端。
02它支援哪些資料型態?我只存文字和數字夠用嗎?
除了常見的整數、數值、字串、布林值,它還支援日期時間、陣列、範圍、UUID、JSON/JSONB、XML、鍵值對(Hstore),以及點、線、多邊形等幾何資料。如果你需要存圖片、聲音或影片這類大型二進位物件,它也有支援。所以不只是文字數字,半結構化資料或地理位置資料都可以放進來。
03資料量很大的時候,查詢會不會越來越慢?
它提供多種索引類型,包括 B-tree、多欄位索引、部分索引、GiST、GIN、BRIN 等,也支援表示式索引和覆蓋索引。查詢規劃器會嘗試找出有效率的執行計畫,並支援平行查詢、資料表分割區、JIT 編譯。不過索引要自己設計,不是裝好就自動變快,需要依照實際查詢模式來建立。
04多人同時讀寫,會不會互相卡住或鎖死?
它採用多版本並行控制(MVCC),讓讀取和寫入不會互相阻擋,也支援 SQL 標準定義的所有交易隔離等級,包括 Serializable。你可以設定明確鎖定或建議性鎖定(Advisory Locks)來控制特定情況的並行行為。但要注意,交易隔離等級和鎖定的設定會影響實際行為,需要依照應用情境調整。
05資料安全方面,它有沒有提供什麼保護機制?
它支援多種身分驗證方式,包括 GSSAPI、SSPI、LDAP、SCRAM-SHA-256、憑證驗證等,也有細緻的存取控制系統,可以做到欄位層級和列層級的安全設定。另外有 Write-ahead Logging(WAL)來確保資料寫入的可靠性,並支援非同步、同步、邏輯複製,以及時間點復原(PITR)和主動備援。
06這套軟體適合什麼樣的人或團隊?
適合需要處理大量結構化資料、重視資料完整性和交易正確性的開發者或團隊。如果你在建置網站後端、內部管理系統、需要跑複雜查詢或報表,而且希望資料庫本身是開放原始碼、不用付授權費,那它會是一個可以考慮的選項。它也適合需要自訂資料型態或函式的人,因為擴充性很強。
07我只會用圖形介面操作,不會寫指令,這樣能用嗎?
它安裝時會附帶 pgAdmin 圖形介面工具,可以用視覺化方式建立資料庫、執行 SQL 查詢、設定使用者權限、備份還原。但要注意,官方資料提到它「內建的 GUI 管理工具有限」,如果習慣用圖形介面做所有事情,可能會覺得某些進階操作還是得回到指令列。另外介面是英文的,沒有官方中文介面。
08我目前只是做個小專案,資料量不大,用它會不會太重?
它功能完整,但相對的也需要花時間學習和設定。如果只是幾百筆資料、單人使用、不需要複雜查詢,用 SQLite 這類輕量資料庫可能更簡單,不需要安裝伺服器、不需要管理使用者權限。不過如果你預期資料會持續成長,或之後要多人同時連線,提早用它可以省下日後搬移資料的麻煩。
09它的介面只有英文,我英文不好,會不會很難上手?
官方介面和文件都是英文,沒有內建中文語系。如果你英文閱讀有困難,操作上會比較吃力。不過它的文件寫得相當完整,社群也很大,網路上可以找到大量中文教學文章和討論。如果你完全無法閱讀英文,可能需要先評估自己能不能接受看英文文件,或考慮其他有中文介面的資料庫工具。
10我聽說它更新很頻繁,這樣會不會一直要升級、很麻煩?
它的版本更新確實算頻繁,近一年內有多次更新。升級時可能需要手動調整,官方資料也提到「升級可能需要手動調整」。如果你不習慣定期維護資料庫,或沒有專門的人負責這塊,頻繁的版本更新可能會造成額外負擔。但如果不更新,安全性漏洞和 bug 修復就無法取得。
11它跟 MySQL Workbench 或 SQLite 比起來,我該怎麼選?
這取決於你的需求。SQLite 是嵌入式資料庫,適合單機、小規模、不需要伺服器管理的場景;MySQL Workbench 是 MySQL 的圖形介面工具,本身不是資料庫。PostgreSQL 則是一套完整的資料庫伺服器,功能更全面,支援更多進階功能(如自訂型態、多種索引、豐富的資料型態)。如果你需要複雜查詢、高並行、資料完整性要求高,它會是比較完整的方案;如果只是簡單存取,SQLite 可能更輕量。
下載與官方連結
postgresql-15.1-1-windows-x64.exe · 連結指向軟體原廠
版本紀錄
- 2026-10-17 PostgreSQL 18.6 358 MB
- 2026-05-18 PostgreSQL 16.14 349 MB
- 2026-05-17 PostgreSQL 17.10 357 MB
再看 5 筆
- 2026-05-15 PostgreSQL 18.4 357 MB
- 2026-02-27 PostgreSQL 16.13 347 MB
- 2026-02-27 PostgreSQL 17.9 354 MB
- 2026-02-27 PostgreSQL 18.3 355 MB
- 2026-02-13 PostgreSQL 17.8 354 MB
這一版改了什麼
What's new in this version:
- Fix failure to remove non-first segments of large tables
- PostgreSQL splits large tables into multiple files (normally with 1GB per file). The logic for dropping a table was broken and would miss removing all but the first such file, in two cases: drops of temporary tables and WAL replay of drops of regular tables. Applications that routinely create multi-gigabyte temporary tables could suffer significant disk space leakage.
- Orphaned temporary-table files are removed during postmaster start, so the mere act of updating to 15.1 is sufficient to clear any leaked temporary-table storage. However, if you suffered any database crashes while using 15.0, and there might have been large tables dropped just before such crashes, it's advisable to check the database directories for files named according to the pattern NNNN.NN. If there is no matching file named just NNNN (without the .NN suffix), these files should be removed manually.
- Fix handling of DEFAULT tokens that appear in a multi-row VALUES clause of an INSERT on an updatable view
- This oversight could lead to “cache lookup failed for type” errors, or in older branches even to crashes.
- Disallow rules named _RETURN that are not ON SELECT
- This avoids confusion between a view's ON SELECT rule and any other rules it may have.
- Avoid failure in EXPLAIN VERBOSE for a query using SEARCH BREADTH FIRST with constant initial values
- Prevent use of MERGE on a partitioned table with foreign-table partitions
- The case isn't supported, and previously threw an incomprehensible error.
- Fix construction of per-partition foreign key constraints while doing ALTER TABLE ATTACH PARTITION
- Previously, incorrect or duplicate constraints could be constructed for the newly-added partition.
- Fix planner failure with extended statistics on partitioned or inherited tables
- Some cases failed with “cache lookup failed for statistics object”
- Fix mis-ordering of WAL operations in fast insert path for GIN indexes
- This mistake is not known to have any negative consequences within core PostgreSQL, but it did cause issues for some extensions
- Fix bugs in logical decoding when replay starts from a point between the beginning of a transaction and the beginning of its subtransaction
- These errors could lead to assertion failures in debug builds, and otherwise to memory leaks
- Accept interrupts in more places during logical decoding
- This ameliorates problems with slow shutdown of replication workers
- Prevent attempts to replicate into a foreign-table partition in replication workers
- Although partitioned tables can have foreign tables as partitions, replicating into such a partition isn't currently supported. The logical replication worker process would crash if it was attempted. Now, an error is thrown.
- Avoid crash after function syntax error in replication workers
- If a syntax error occurred in a SQL-language or PL/pgSQL-language CREATE FUNCTION or DO command executed in a logical replication worker, the worker process would crash with a null pointer dereference or assertion failure
- Avoid double call of the shutdown callback of an archiver module
- Add plan-time check for attempted access to a table that has no table access method
- This prevents a crash in some catalog-corruption scenarios, for example use of a view whose ON SELECT rule is missing
- Prevent postmaster crash when shared-memory state is corrupted
- The postmaster process is supposed to survive and initiate a database restart if shared memory becomes corrupted, but one bit of code was being insufficiently cautious about that
- In libpq, handle single-row mode correctly when pipelining
- The single-row flag was not reset at the correct time if pipeline mode was also active
- Fix psql's exit status when a command-line query is canceled
- psql -c query would exit successfully if the query was canceled. Fix it to exit with nonzero status, as in other error cases
- Allow cross-platform tablespace relocation in pg_basebackup
- Allow the remote path in --tablespace-mapping to be either a Unix-style or Windows-style absolute path, since the source server could be on a different OS than the local system.
- Fix pg_dump's failure to dump comments attached to some CHECK constraints
- Fix CREATE DATABASE to allow its oid parameter to exceed 231
- This oversight prevented pg_upgrade from succeeding when the source installation contained databases with OIDs larger than that
- In pg_stat_statements, fix access to already-freed memory
- This occurred if pg_stat_statements tracked a ROLLBACK command issued via extended query protocol. In debug builds it consistently led to an assertion failure. In production builds there would often be no visible ill effect; but if the freed memory had already been reused, the likely result would be to store garbage for the query string.
- Fix incompatibilities with LLVM 15
- Allow use of __sync_lock_test_and_set() for spinlocks on any machine
- This eases porting to new machine architectures, at least if you're using a compiler that supports this GCC builtin function
- Rename symbol REF to REF_P to avoid compile failure on recent macOS
- Avoid using sprintf, to avoid compile-time deprecation warnings
- Update time zone data files to tzdata release 2022f for DST law changes in Chile, Fiji, Iran, Jordan, Mexico, Palestine, and Syria, plus historical corrections for Chile, Crimea, Iran, and Mexico.
- Also, the Europe/Kiev zone has been renamed to Europe/Kyiv. Also, the following zones have been merged into nearby, more-populous zones whose clocks have agreed with them since 1970: Antarctica/Vostok, Asia/Brunei, Asia/Kuala_Lumpur, Atlantic/Reykjavik, Europe/Amsterdam, Europe/Copenhagen, Europe/Luxembourg, Europe/Monaco, Europe/Oslo, Europe/Stockholm, Indian/Christmas, Indian/Cocos, Indian/Kerguelen, Indian/Mahe, Indian/Reunion, Pacific/Chuuk, Pacific/Funafuti, Pacific/Majuro, Pacific/Pohnpei, Pacific/Wake and Pacific/Wallis. (This indirectly affects zones that were already links to one of these: Arctic/Longyearbyen, Atlantic/Jan_Mayen, Iceland, Pacific/Ponape, Pacific/Truk, and Pacific/Yap.) America/Nipigon, America/Rainy_River, America/Thunder_Bay, Europe/Uzhgorod, and Europe/Zaporozhye were also merged into nearby zones after discovering that their claimed post-1970 differences from those zones seem to have been errors. In all these cases, the previous zone name remains as an alias; but the actual data is that of the zone that was merged into.
- These zone mergers result in loss of pre-1970 timezone history for the merged zones, which may be troublesome for applications expecting consistency of timestamptz display. As an example, the stored value 1944-06-01 12:00 UTC would previously display as 1944-06-01 13:00:00+01 if the Europe/Stockholm zone is selected, but now it will read out as 1944-06-01 14:00:00+02.
- It is possible to build the time zone data files with options that will restore the older zone data, but that choice also inserts a lot of other old (and typically poorly-attested) zone data, resulting in more total changes from the previous release than accepting these upstream changes does. PostgreSQL has chosen to ship the tzdb data as-recommended, and so far as we are aware most major operating system distributions are doing likewise. However, if these changes cause significant problems for your application, a possible solution is to install a local build of the time zone data files using tzdb's backwards-compatibility options (see their PACKRATDATA and PACKRATLIST options).