Partitioning & ShardingPartitioning & Sharding

Thuộc bộ kiến thức PostgreSQL DBA Roadmap.

Tổng quan

Một bảng ban đầu nhỏ và hợp lý, sau vài năm và vài trăm triệu dòng, có thể trở thành thứ khiến mọi tác vụ vận hành trở nên đau đầu: sequential scan mất hàng phút thay vì mili-giây, CREATE INDEX khóa bảng trong một khoảng thời gian khó chịu, VACUUM không theo kịp lượng dead tuple sinh ra, và một lần backup bằng pg_dump kéo dài đủ lâu để đe dọa cửa sổ bảo trì. Không phải vì PostgreSQL kém trong việc lưu trữ bảng lớn — mà vì một file vật lý duy nhất (hoặc tập hợp các file segment 1 GB) buộc mọi thao tác, từ planning đến vacuuming, phải xử lý cả bảng như một khối không thể chia nhỏ.

Partitioning chính là câu trả lời của PostgreSQL: chia một bảng logic lớn thành nhiều bảng vật lý nhỏ hơn (“partition”), trong khi mọi client, ứng dụng, và câu query vẫn tương tác như thể đang làm việc với một bảng duy nhất. Làm đúng cách, kỹ thuật này biến việc scan toàn bộ 500 triệu dòng thành scan đúng 2 triệu dòng thực sự cần thiết, biến một lệnh bulk delete kéo dài hàng giờ thành một DROP TABLE gần như tức thì, và biến việc bảo trì index cùng VACUUM thành công việc có thể thực hiện từng partition một thay vì toàn bộ cùng lúc.

Bài viết này bao quát cơ chế declarative partitioning có sẵn của PostgreSQL (range, list, và hash), cách partition pruning khiến tất cả những điều trên trở nên đáng giá — và cách nó âm thầm không xảy ra khi query không được viết đúng cách — các khía cạnh vận hành khi bảo trì partition theo thời gian, và một chủ đề liên quan nhưng khác biệt: sharding — phân tán dữ liệu trên nhiều server thay vì nhiều bảng trên một server.

Kiến thức nền tảng

Partitioning thực sự là gì

Declarative partitioning, được giới thiệu từ PostgreSQL 10 và hoàn thiện dần qua các bản 11–17, cho phép bạn định nghĩa một parent table không chứa dữ liệu thực — nó chỉ khai báo chiến lược và partition key — và một hoặc nhiều child partition là các bảng thông thường thực sự chứa dữ liệu. Từ góc nhìn của ứng dụng chỉ có một bảng duy nhất: bạn INSERT, SELECT, UPDATE, DELETE trên tên của parent table, và PostgreSQL tự động điều hướng từng dòng đến đúng partition dựa trên partition key.

-- Parent table: chỉ có schema, chưa chọn chiến lược partition (sẽ chọn ở phần dưới)
CREATE TABLE events (
    id          bigint GENERATED ALWAYS AS IDENTITY,
    tenant_id   int         NOT NULL,
    region      text        NOT NULL,
    event_type  text        NOT NULL,
    payload     jsonb,
    created_at  timestamptz NOT NULL DEFAULT now(),
    PRIMARY KEY (id, created_at)          -- partition key phải nằm trong mọi unique/PK constraint
) PARTITION BY RANGE (created_at);

Chú ý phần primary key: PRIMARY KEY (id, created_at) thay vì chỉ PRIMARY KEY (id). Đây là hệ quả trực tiếp của một quy tắc sẽ được nói kỹ hơn bên dưới — mọi unique constraint (kể cả primary key) trên một partitioned table đều phải bao gồm partition key như một trong các cột, bởi vì tính duy nhất trong PostgreSQL được đảm bảo theo từng partition, chứ không phải trên toàn bộ partitioned table.

Đây là cách làm khác hẳn kỹ thuật “partitioning” kiểu cũ mà một số DBA vẫn còn nhớ từ PostgreSQL 9.x trở về trước: dùng table inheritance kết hợp CHECK constraint và trigger để điều hướng dữ liệu. Declarative partitioning đã thay thế cách làm đó cho hầu như mọi công việc mới — nó nhanh hơn, planner hiểu nó một cách tự nhiên, và việc điều hướng là tự động thay vì phải qua trigger. Vẫn đáng biết lịch sử này tồn tại, chủ yếu để nhận ra nó nếu bạn thừa hưởng một database được xây dựng từ trước PostgreSQL 10.

Ba chiến lược partitioning

PostgreSQL hỗ trợ ba cách để quyết định một dòng dữ liệu thuộc về partition nào: RANGE, LIST, và HASH. Cả ba chia sẻ cùng cơ chế parent/child — chỉ khác nhau ở quy tắc điều hướng một dòng.

Range partitioning

Range partitioning gán dòng dữ liệu vào partition dựa trên việc giá trị partition key rơi vào khoảng liên tục nào. Đây là kiểu phổ biến nhất trên một cột timestamp hoặc date, vì dữ liệu time-series — log, event, metric, order, audit trail — có một partition key tăng dần tự nhiên và một chính sách retention rõ ràng.

CREATE TABLE events (
    id          bigint GENERATED ALWAYS AS IDENTITY,
    tenant_id   int         NOT NULL,
    region      text        NOT NULL,
    event_type  text        NOT NULL,
    payload     jsonb,
    created_at  timestamptz NOT NULL DEFAULT now(),
    PRIMARY KEY (id, created_at)
) PARTITION BY RANGE (created_at);

-- Mỗi tháng một partition
CREATE TABLE events_2026_05 PARTITION OF events
    FOR VALUES FROM ('2026-05-01') TO ('2026-06-01');

CREATE TABLE events_2026_06 PARTITION OF events
    FOR VALUES FROM ('2026-06-01') TO ('2026-07-01');

CREATE TABLE events_2026_07 PARTITION OF events
    FOR VALUES FROM ('2026-07-01') TO ('2026-08-01');

-- Partition "bắt tất cả" cho các dòng nằm ngoài mọi range đã tạo (không bắt buộc nhưng nên có)
CREATE TABLE events_default PARTITION OF events DEFAULT;

FOR VALUES FROM (...) TO (...) là một khoảng nửa-mở (half-open interval): FROM bao gồm giá trị biên, TO không bao gồm giá trị biên. Đây là lý do các giá trị biên khớp gọn gàng giữa các tháng liên tiếp — 2026-06-01 vừa là biên trên (loại trừ) của tháng 5, vừa là biên dưới (bao gồm) của tháng 6, không có khoảng hở và không chồng lấn.

Tính năng “sát thủ” của range partitioning theo thời gian chính là retention. Xóa một năm log cũ bằng DELETE FROM events WHERE created_at < now() - interval '1 year' trên một bảng 500 triệu dòng không được partition nghĩa là phải scan các dòng khớp điều kiện, sinh WAL cho từng dòng bị xóa, để lại dead tuple cho VACUUM dọn dẹp, và giữ lock suốt quá trình đó. Cách làm tương đương trên một bảng đã partition là:

-- Detach và drop cả một tháng chỉ trong vài mili-giây, thay vì DELETE chậm từng dòng
ALTER TABLE events DETACH PARTITION events_2025_05;
DROP TABLE events_2025_05;

Đây là một thao tác metadata — không cần scan từng dòng, không gây bloat WAL từ hàng triệu tuple bị xóa, gần như tức thì bất kể partition chứa bao nhiêu dòng. Với bất kỳ bảng nào có cửa sổ retention xoay vòng (giữ 90 ngày, giữ 2 năm, giữ 13 tháng), riêng lợi ích này đã đủ để biện minh cho range partitioning.

List partitioning

List partitioning gán dòng dữ liệu vào partition dựa trên việc thuộc về một tập giá trị rời rạc, tường minh, thay vì một khoảng liên tục. Nó phù hợp tự nhiên ở bất cứ đâu dữ liệu vốn đã rơi vào một số ít danh mục có tên gọi: region, tenant, quốc gia, status, hoặc bất kỳ cột nào có từ vựng giới hạn, đã biết trước.

CREATE TABLE customer_data (
    id          bigint GENERATED ALWAYS AS IDENTITY,
    customer_id bigint      NOT NULL,
    region      text        NOT NULL,
    full_name   text,
    email       text,
    created_at  timestamptz NOT NULL DEFAULT now(),
    PRIMARY KEY (id, region)
) PARTITION BY LIST (region);

CREATE TABLE customer_data_eu PARTITION OF customer_data
    FOR VALUES IN ('DE', 'FR', 'NL', 'IT', 'ES');

CREATE TABLE customer_data_us PARTITION OF customer_data
    FOR VALUES IN ('US', 'CA');

CREATE TABLE customer_data_apac PARTITION OF customer_data
    FOR VALUES IN ('SG', 'JP', 'AU', 'IN');

CREATE TABLE customer_data_other PARTITION OF customer_data DEFAULT;

Ngoài khía cạnh hiệu năng, list partitioning theo region còn là công cụ phổ biến cho yêu cầu về data residency và tuân thủ (compliance) (GDPR và các quy định tương tự): nếu dữ liệu khách hàng EU bắt buộc phải nằm vật lý trong khu vực EU, customer_data_eu có thể nằm trên một tablespace lưu trữ tại vùng EU trong khi customer_data_us nằm ở nơi khác, tất cả trong khi ứng dụng vẫn chỉ query một bảng logic customer_data duy nhất.

Hash partitioning

Hash partitioning là lựa chọn khi không có ranh giới range hay list tự nhiên nào, nhưng bạn vẫn muốn có lợi ích vận hành của việc chia nhỏ một bảng khổng lồ — thường là để phân tán đều tải ghi và dung lượng lưu trữ, hoặc để cho phép các thao tác bảo trì (vacuum, reindex) chạy song song, độc lập giữa các partition. PostgreSQL băm (hash) giá trị partition key và gán dòng vào một trong N partition dựa trên (giá trị hash) MOD N, sử dụng các cặp REMAINDER/MODULUS phải phủ kín toàn bộ không gian giá trị.

CREATE TABLE sessions (
    id          uuid        NOT NULL DEFAULT gen_random_uuid(),
    user_id     bigint      NOT NULL,
    started_at  timestamptz NOT NULL DEFAULT now(),
    data        jsonb,
    PRIMARY KEY (id, user_id)
) PARTITION BY HASH (user_id);

-- 4 partition phủ kín toàn bộ hash space: modulus 4, remainder 0..3
CREATE TABLE sessions_p0 PARTITION OF sessions
    FOR VALUES WITH (MODULUS 4, REMAINDER 0);
CREATE TABLE sessions_p1 PARTITION OF sessions
    FOR VALUES WITH (MODULUS 4, REMAINDER 1);
CREATE TABLE sessions_p2 PARTITION OF sessions
    FOR VALUES WITH (MODULUS 4, REMAINDER 2);
CREATE TABLE sessions_p3 PARTITION OF sessions
    FOR VALUES WITH (MODULUS 4, REMAINDER 3);

Hash partitioning không có partition DEFAULT — mọi giá trị hash có thể có đều được đảm bảo rơi vào đúng một trong các nhóm MODULUS/REMAINDER, nên không tồn tại trường hợp “còn sót lại” để bắt. Đánh đổi so với range hay list partitioning là các hash partition thường không mang ý nghĩa gì cho việc pruning trong hầu hết query thực tế — bạn hiếm khi viết WHERE user_id = 12345 và nghĩ theo hướng “partition nào”, nên hash partitioning giúp về mặt vận hành (đơn vị nhỏ hơn để vacuum/reindex, phân tán I/O qua nhiều tablespace) nhiều hơn là giúp giảm latency của query, trừ khi query thực sự lọc bằng một điều kiện equality trên hash key.

Khái niệm chính

Partition pruning

Partition pruning là cơ chế khiến tất cả những điều ở trên trở nên đáng giá: khi query planner có thể chứng minh, từ mệnh đề WHERE và ranh giới partition, rằng một partition không thể chứa dòng nào khớp điều kiện, nó sẽ loại bỏ hoàn toàn partition đó khỏi plan — không scan, không I/O, thậm chí không được xem xét lúc thực thi (với runtime pruning, điều này thậm chí có thể xảy ra với các query tham số hóa và điều kiện JOIN được phát hiện trong lúc thực thi, chứ không chỉ với hằng số đã biết tại thời điểm lập plan).

-- Được prune: planner biết chỉ events_2026_06 có thể khớp, và bỏ qua mọi partition khác
EXPLAIN (ANALYZE, BUFFERS)
SELECT count(*) FROM events
WHERE created_at >= '2026-06-01' AND created_at < '2026-06-15';

-- KHÔNG được prune: không có filter trên partition key (created_at), phải scan mọi partition
EXPLAIN (ANALYZE, BUFFERS)
SELECT count(*) FROM events
WHERE event_type = 'login_failed';

Hệ quả quan trọng, dễ bị bỏ sót: pruning chỉ có tác dụng nếu query thực sự filter trên partition key. Một query chỉ filter trên event_type sẽ không được lợi gì từ việc partition theo range created_at — planner buộc phải scan từng partition một, vì bất kỳ partition nào cũng có thể chứa một dòng login_failed. Trong tình huống đó, partitioning chỉ thêm overhead của việc lập plan phức tạp hơn và nhiều executor node theo từng partition mà không mang lại lợi ích chính của nó; một index tốt trên event_type sẽ giúp ích nhiều hơn, hoặc cần xem xét partition theo một key khác, hoặc (thường là câu trả lời đúng) áp dụng cách tiếp cận kết hợp với created_at xuất hiện trong mọi query cùng các điều kiện lọc khác.

Đây chính là lý do nên đọc bài viết này cùng với ./10-query-planning-and-performance-tuning.md — pruning là một hành vi của planner, và cách đáng tin cậy duy nhất để biết nó đã xảy ra là xem plan:

EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM events
WHERE created_at >= '2026-06-01' AND created_at < '2026-06-02'
  AND tenant_id = 42;

Trong output của EXPLAIN, hãy tìm node Append hoặc Merge Append có danh sách con chỉ gồm các partition bạn mong đợi — nếu một query “chạy trên bảng đã partition” mà vẫn chậm, và plan cho thấy mọi partition đều bị scan bên dưới Append, đó chính là dấu hiệu tương đương với việc thiếu index: schema thì đúng, nhưng query lại không được viết để tận dụng nó. Đừng bao giờ cho rằng pruning đã xảy ra chỉ vì bảng đã được partition — hãy xác minh mỗi lần có một pattern query mới hoặc thay đổi.

Bảo trì partition

Các bảng range-partitioned theo cửa sổ thời gian xoay vòng cần được tạo partition mới trước khi dữ liệu của khoảng thời gian đó bắt đầu đến, và cần rút bỏ (retire) các partition cũ khi chúng vượt quá cửa sổ retention. Nếu bỏ qua việc này, các dòng mới hoặc sẽ bị từ chối (nếu không có partition khớp và không có DEFAULT) hoặc âm thầm chất đống trong một partition DEFAULT vốn không được đánh index cho mục đích đó, làm mất đi toàn bộ ý nghĩa của việc partition.

-- Tạo trước partition của tháng tiếp theo, trước khi dữ liệu tháng 7 bắt đầu đến
CREATE TABLE events_2026_08 PARTITION OF events
    FOR VALUES FROM ('2026-08-01') TO ('2026-09-01');

Hai công cụ giúp việc này an toàn dưới tải: ATTACH/DETACH PARTITION cho phép bạn xây dựng hoặc kiểm chứng dữ liệu của một partition ở ngoài (out-of-band) và chỉ giữ lock trong thời gian ngắn để attach hoặc detach nó, còn CREATE TABLE ... (LIKE events INCLUDING ALL) cho phép bạn tạo trước một bảng có cùng cấu trúc trước khi biến nó thành partition.

-- Xây dựng một bảng có cấu trúc giống partition ở "bên ngoài", nạp/kiểm chứng dữ liệu, rồi attach
CREATE TABLE events_2026_08 (LIKE events INCLUDING ALL);
-- ... bulk load hoặc migrate dữ liệu vào events_2026_08 tại đây ...
ALTER TABLE events ATTACH PARTITION events_2026_08
    FOR VALUES FROM ('2026-08-01') TO ('2026-09-01');

-- Detach một partition để archive riêng, không xóa ngay
ALTER TABLE events DETACH PARTITION events_2024_01;

Làm việc này bằng tay mỗi tháng không phải là thói quen vận hành có thể mở rộng — đây là kiểu tác vụ dễ bị quên cho đến khi ca trực phát hiện ra không có partition nào cho ngày hôm nay. Trong thực tế, việc này gần như luôn được tự động hóa, hoặc bằng một job theo lịch (cron, CronJob của Kubernetes, hay bộ điều phối bất kỳ) chạy một script nhỏ để tạo trước N partition tiếp theo và drop/detach các partition đã quá hạn retention, hoặc bằng extension pg_partman, vốn quản lý chính xác vòng đời này — tạo trước theo một cửa sổ “premake” có thể cấu hình, drop/detach dựa trên retention, thậm chí migrate ngầm các bảng chưa partition có sẵn sang cấu trúc đã partition.

Constraint và index trên bảng đã partition

Index trên một bảng đã partition có thể được khai báo một lần duy nhất trên parent, và PostgreSQL sẽ tự động lan truyền một index tương đương lên mọi partition hiện có lẫn tương lai:

-- Khai báo một lần trên parent; PostgreSQL tạo index tương ứng trên mọi partition
CREATE INDEX idx_events_tenant_type ON events (tenant_id, event_type);

-- Partition mới attach sau này cũng tự động có index tương đương
CREATE TABLE events_2026_09 PARTITION OF events
    FOR VALUES FROM ('2026-09-01') TO ('2026-10-01');
-- events_2026_09 đã có idx_events_tenant_type_<suffix> ngay tại thời điểm này

Tuy nhiên bên dưới, không hề có một index vật lý duy nhất trải rộng qua mọi partition — mỗi partition có index riêng, độc lập, được xây dựng trên dữ liệu của chính nó (có thể thấy qua \d events_2026_09 như một đối tượng index riêng biệt), và PostgreSQL chỉ giữ cho định nghĩa index trên parent và tập các index theo từng partition luôn nhất quán khi partition được thêm/bớt. Điều này quan trọng đối với bảo trì: REINDEX hay VACUUM vẫn diễn ra theo từng partition, và đây chính là phần lớn lý do partitioning có tác dụng — các index nhỏ hơn, độc lập rebuild và vacuum nhanh hơn một index khổng lồ duy nhất.

Unique constraint (và primary key, về bản chất chỉ là unique constraint cộng thêm NOT NULL) có một yêu cầu bắt buộc đáng ghi nhớ ngay từ đầu: partition key phải là một phần của mọi unique constraint trên bảng đã partition. Đây không phải khuyến nghị về phong cách viết code — PostgreSQL đảm bảo tính duy nhất trong phạm vi từng partition một cách độc lập, nên nó không có cách nào đảm bảo tính duy nhất toàn cục của một key không chứa partition key, và sẽ từ chối tạo constraint nếu vi phạm:

-- Câu này SẼ LỖI: unique constraint không bao gồm partition key (created_at)
ALTER TABLE events ADD CONSTRAINT events_id_unique UNIQUE (id);
-- ERROR: unique constraint on partitioned table must include all partitioning columns

-- Câu này THÀNH CÔNG: đã bao gồm partition key
ALTER TABLE events ADD CONSTRAINT events_id_created_unique UNIQUE (id, created_at);

Trong thực tế, điều này có nghĩa là một id tự tăng đơn thuần không còn là bảo đảm duy nhất duy nhất bạn có thể dựa vào trên một bảng đã partition — bạn hoặc chấp nhận một khóa composite bao gồm cột partition (như trong các ví dụ xuyên suốt bài viết này), hoặc đảm bảo tính duy nhất toàn cục của id bằng cách khác (một bộ sinh giá trị đã duy nhất sẵn theo cấu trúc, như bigint GENERATED ALWAYS AS IDENTITY được sinh từ một nguồn tập trung, hoặc UUID, chấp nhận rằng bản thân PostgreSQL sẽ không kiểm tra lại điều đó xuyên suốt các partition).

Sharding so với partitioning

Partitioning, như đã trình bày ở trên, chia một bảng logic thành nhiều bảng vật lý nhưng tất cả vẫn nằm trên một instance PostgreSQL duy nhất. Nó giải quyết vấn đề về kích thước scan, kích thước index, thời gian vacuum, và độ chi tiết của bảo trì, nhưng mọi partition vẫn cạnh tranh cùng CPU, RAM, và I/O đĩa của chính máy đó — luôn có một giới hạn trên cho lượng tải mà phần cứng của một instance duy nhất có thể hấp thụ, dù bảng có được partition tốt đến đâu.

Sharding giải quyết một vấn đề khác: phân tán dữ liệu qua nhiều instance PostgreSQL riêng biệt, để tổng năng lực (CPU, RAM, đĩa, số connection) mở rộng bằng cách thêm máy chứ không phải bằng cách làm cho một máy lớn hơn. Trong khi partitioning là một tính năng có sẵn, hạng nhất của PostgreSQL, thì PostgreSQL thuần không có sharding có sẵn — không có cú pháp CREATE TABLE ... SHARD BY nào phân tán dữ liệu qua nhiều server ngay trong hộp. Để đạt được khả năng mở rộng theo chiều ngang (horizontal scale-out) với PostgreSQL, bạn cần chọn (hoặc kết hợp) một trong vài hướng tiếp cận sau:

• Sharding ở tầng ứng dụng (application-level sharding). Chính ứng dụng sở hữu logic điều hướng: với một tenant_id hay customer_id, nó tính toán (thường qua hash đơn giản hoặc bảng tra cứu) instance PostgreSQL nào trong số nhiều instance đang chứa dữ liệu của thực thể đó, và kết nối trực tiếp đến instance đó. Cách này dễ suy luận và không cần extension đặc biệt nào, nhưng mọi nơi trong codebase truy vấn database đều phải biết về logic điều hướng shard, join và transaction xuyên shard trở thành vấn đề của ứng dụng, và việc rebalance shard khi dữ liệu lớn dần là một quá trình migration thủ công, tùy biến theo từng trường hợp.
• Foreign Data Wrapper (postgres_fdw). Một instance PostgreSQL có thể định nghĩa các foreign table trỏ đến bảng trên các instance PostgreSQL khác, cho phép một query chạm đến nhiều server thông qua SQL thông thường. Đây thiên về công cụ liên kết/tích hợp (federation) hơn là một giải pháp sharding thực sự — nó có thể kết hợp dữ liệu từ nhiều database, nhưng hiệu năng query và đảm bảo transaction xuyên các foreign server yếu hơn đáng kể so với thực thi phân tán thực sự.
• Citus, một extension của PostgreSQL (mã nguồn mở, và là nền tảng của Azure Cosmos DB for PostgreSQL) biến một tập hợp các node PostgreSQL thông thường thành một database phân tán: bạn khai báo một “distribution column” trên một bảng, Citus tự động phân tán (shard) các dòng của bảng đó qua các worker node, và viết lại các query đến thành một plan phân tán — song song hóa qua các shard, đẩy các điều kiện filter và join xuống worker, và tổng hợp kết quả tại một coordinator node. Đây là thứ gần nhất với “sharding như một tính năng hạng nhất” hiện có cho PostgreSQL, đổi lại phải chấp nhận extension này cùng các ràng buộc của nó (ví dụ, một số pattern join xuyên shard hoặc unique constraint toàn cục cần được cân nhắc cẩn thận, tương tự tinh thần của quy tắc “partition key phải nằm trong unique constraint” nói trên, nhưng áp dụng cho toàn bộ cluster thay vì một bảng đơn lẻ).

Hai khái niệm này bổ sung cho nhau chứ không cạnh tranh, và các hệ thống production ở quy mô lớn thường dùng cả hai cùng lúc: mỗi shard (dù được xây dựng thủ công ở tầng ứng dụng hay là một worker node của Citus) tự nó là một instance PostgreSQL chứa một phần dữ liệu — chẳng hạn, một khoảng tenant_id — và bên trong instance đó, các bảng nó chứa lại tiếp tục được chia nhỏ bằng declarative partitioning thông thường theo, ví dụ, created_at. Partitioning tổ chức dữ liệu bên trong một instance; sharding phân tán dữ liệu qua nhiều instance; một hệ thống quy mô lớn được thiết kế tốt thường làm cả hai, mỗi thứ giải quyết vấn đề ở tầng phù hợp với nó. Nếu bạn muốn đọc tiếp sang khía cạnh rộng hơn của hệ thống phân tán (consistent hashing, replication, các distributed query engine như worker của Citus hoặc các hệ thống hoàn toàn nằm ngoài PostgreSQL như Spark hay một data warehouse), xem thêm ../data-engineer/en/10-big-data-and-distributed-computing.md.

Best Practices

Partitioning không phải là mặc định bạn nên áp dụng cho mọi bảng vượt qua một ngưỡng số dòng nào đó — đây là một sự đánh đổi có chủ đích: thêm độ phức tạp vận hành và lập plan để đổi lấy việc giải quyết một điểm đau cụ thể, đã thực sự được quan sát thấy. Một bảng đã partition có nhiều thành phần chuyển động hơn một bảng thường: mỗi partition thêm vào sẽ cộng thêm một chút overhead lập plan (nhân với hàng nghìn query đồng thời, con số này trở nên đáng kể), các job bảo trì (tạo/rút bỏ partition) trở thành một thứ khác có thể âm thầm thất bại, và các ràng buộc như yêu cầu bắt buộc partition key trong unique index sẽ lan sang các giả định ở tầng ứng dụng về primary key. Tín hiệu đúng để bắt đầu partition là bằng chứng, không phải dự đoán trước: các lần VACUUM bị tụt lại phía sau hoặc mất hàng giờ, việc build index hay REINDEX cần đến cửa sổ bảo trì riêng, backup vượt quá cửa sổ cho phép, hoặc query plan bị chi phối bởi việc scan nhiều dữ liệu hơn hẳn mức một query thực sự cần về mặt logic. Partition một bảng 2 triệu dòng “vì có thể sau này nó sẽ lớn” chỉ thêm độ phức tạp thực sự mà không mang lại lợi ích hiện tại nào, đây là ví dụ điển hình của tối ưu hóa sớm (premature optimization); trong khi partition một bảng events 500 triệu dòng, vẫn đang tăng, mất 6 giờ để VACUUM gần như là bắt buộc.

Khi đã quyết định partition, hãy chọn chiến lược khớp với pattern truy cập thực tế thay vì chọn thứ thuận tiện về mặt cấu trúc: range partitioning theo thời gian chỉ đáng giá nếu các query thường xuyên filter theo một khoảng thời gian (và càng đáng giá hơn nếu có chính sách retention biến thành DROP/DETACH thay vì DELETE); list partitioning theo một cột phân loại chỉ giúp ích nếu các query thường xuyên filter theo danh mục đó, hoặc nếu có một yêu cầu bắt buộc (như data residency) buộc phải chia theo cách đó bất kể pattern query; hash partitioning là công cụ đúng đắn cụ thể khi không có range hay danh mục tự nhiên nào để tận dụng và mục tiêu thực sự là phân tán đều tải lưu trữ và bảo trì, chứ không phải tăng tốc một query cụ thể nào thông qua pruning. Dù chọn chiến lược nào, hãy xem partition pruning là thứ cần xác minh, không phải mặc định là đúng — chạy EXPLAIN (ANALYZE, BUFFERS) với các query thực tế, đúng hình dạng production sau khi partition, và xác nhận các node con của Append đúng là các partition bạn mong đợi, đồng thời xem lại bất kỳ query nào có điều kiện filter không chạm đến partition key, vì query đó đang phải trả overhead của partitioning mà không nhận được lợi ích của nó.

Cuối cùng, hãy dự trù vòng đời bảo trì ngay từ đầu thay vì để sau: quyết định cửa sổ premake (tạo trước partition mới bao xa) và cửa sổ retention (partition cũ tồn tại bao lâu) ngay từ đầu, tự động hóa cả hai bằng một job theo lịch hoặc pg_partman thay vì trông chờ con người nhớ chạy script hàng tháng, và ghi nhớ rằng thiếu partition tương lai là một kiểu lỗi cứng (insert hoặc báo lỗi hoặc rơi vào một partition DEFAULT không được đánh index đúng cách) trong khi thiếu việc rút bỏ partition cũ là một kiểu lỗi âm thầm, từ từ (các partition cũ lặng lẽ tích tụ và bào mòn chính lợi ích mà partitioning được kỳ vọng mang lại). Nếu và khi năng lực của một instance duy nhất mới thực sự là điểm nghẽn, chứ không phải đặc tính riêng của từng bảng, đó là tín hiệu để nhìn sang sharding — ở tầng ứng dụng hoặc qua Citus — thay vì cố giải quyết vấn đề năng lực đa-server bằng cách partition mạnh hơn trên một máy duy nhất.

Tài liệu tham khảo

• PostgreSQL Documentation — Table Partitioning
• PostgreSQL Documentation — Partition Pruning
• PostgreSQL Documentation — CREATE TABLE (partition syntax)
• pg_partman — Extension for automated partition management
• Citus Documentation — Distributed PostgreSQL
• postgres_fdw — Foreign Data Wrapper for PostgreSQL
• PostgreSQL Wiki — Sharding

Xem thêm: ./08-indexing-strategies.md, ./10-query-planning-and-performance-tuning.md, ../data-engineer/en/10-big-data-and-distributed-computing.md.

-- The parent table: schema only, no partitioning strategy chosen yet = pick one below
CREATE TABLE events (
    id          bigint GENERATED ALWAYS AS IDENTITY,
    tenant_id   int         NOT NULL,
    region      text        NOT NULL,
    event_type  text        NOT NULL,
    payload     jsonb,
    created_at  timestamptz NOT NULL DEFAULT now(),
    PRIMARY KEY (id, created_at)          -- partition key must be part of any unique/PK constraint
) PARTITION BY RANGE (created_at);

CREATE TABLE events (
    id          bigint GENERATED ALWAYS AS IDENTITY,
    tenant_id   int         NOT NULL,
    region      text        NOT NULL,
    event_type  text        NOT NULL,
    payload     jsonb,
    created_at  timestamptz NOT NULL DEFAULT now(),
    PRIMARY KEY (id, created_at)
) PARTITION BY RANGE (created_at);

-- One partition per month
CREATE TABLE events_2026_05 PARTITION OF events
    FOR VALUES FROM ('2026-05-01') TO ('2026-06-01');

CREATE TABLE events_2026_06 PARTITION OF events
    FOR VALUES FROM ('2026-06-01') TO ('2026-07-01');

CREATE TABLE events_2026_07 PARTITION OF events
    FOR VALUES FROM ('2026-07-01') TO ('2026-08-01');

-- A catch-all for rows outside any explicitly created range (optional but recommended)
CREATE TABLE events_default PARTITION OF events DEFAULT;

-- Detach and drop a whole month in milliseconds, instead of a slow row-by-row DELETE
ALTER TABLE events DETACH PARTITION events_2025_05;
DROP TABLE events_2025_05;

CREATE TABLE customer_data (
    id          bigint GENERATED ALWAYS AS IDENTITY,
    customer_id bigint      NOT NULL,
    region      text        NOT NULL,
    full_name   text,
    email       text,
    created_at  timestamptz NOT NULL DEFAULT now(),
    PRIMARY KEY (id, region)
) PARTITION BY LIST (region);

CREATE TABLE customer_data_eu PARTITION OF customer_data
    FOR VALUES IN ('DE', 'FR', 'NL', 'IT', 'ES');

CREATE TABLE customer_data_us PARTITION OF customer_data
    FOR VALUES IN ('US', 'CA');

CREATE TABLE customer_data_apac PARTITION OF customer_data
    FOR VALUES IN ('SG', 'JP', 'AU', 'IN');

CREATE TABLE customer_data_other PARTITION OF customer_data DEFAULT;

CREATE TABLE sessions (
    id          uuid        NOT NULL DEFAULT gen_random_uuid(),
    user_id     bigint      NOT NULL,
    started_at  timestamptz NOT NULL DEFAULT now(),
    data        jsonb,
    PRIMARY KEY (id, user_id)
) PARTITION BY HASH (user_id);

-- 4 partitions covering the full hash space: modulus 4, remainders 0..3
CREATE TABLE sessions_p0 PARTITION OF sessions
    FOR VALUES WITH (MODULUS 4, REMAINDER 0);
CREATE TABLE sessions_p1 PARTITION OF sessions
    FOR VALUES WITH (MODULUS 4, REMAINDER 1);
CREATE TABLE sessions_p2 PARTITION OF sessions
    FOR VALUES WITH (MODULUS 4, REMAINDER 2);
CREATE TABLE sessions_p3 PARTITION OF sessions
    FOR VALUES WITH (MODULUS 4, REMAINDER 3);

-- Pruned: the planner knows only events_2026_06 can match, and skips every other partition
EXPLAIN (ANALYZE, BUFFERS)
SELECT count(*) FROM events
WHERE created_at >= '2026-06-01' AND created_at < '2026-06-15';

-- NOT pruned: no filter on the partition key (created_at), every partition must be scanned
EXPLAIN (ANALYZE, BUFFERS)
SELECT count(*) FROM events
WHERE event_type = 'login_failed';

EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM events
WHERE created_at >= '2026-06-01' AND created_at < '2026-06-02'
  AND tenant_id = 42;

-- Create next month's partition ahead of time, before July data starts arriving
CREATE TABLE events_2026_08 PARTITION OF events
    FOR VALUES FROM ('2026-08-01') TO ('2026-09-01');

-- Build a partition-shaped table off to the side, load/validate its data, then attach it
CREATE TABLE events_2026_08 (LIKE events INCLUDING ALL);
-- ... bulk load or migrate data into events_2026_08 here ...
ALTER TABLE events ATTACH PARTITION events_2026_08
    FOR VALUES FROM ('2026-08-01') TO ('2026-09-01');

-- Detach a partition to archive it separately, without deleting it immediately
ALTER TABLE events DETACH PARTITION events_2024_01;

-- Declared once on the parent; PostgreSQL creates a matching index on every partition
CREATE INDEX idx_events_tenant_type ON events (tenant_id, event_type);

-- New partitions attached later automatically get an equivalent index too
CREATE TABLE events_2026_09 PARTITION OF events
    FOR VALUES FROM ('2026-09-01') TO ('2026-10-01');
-- events_2026_09 already has idx_events_tenant_type_<suffix> at this point

-- This FAILS: unique constraint doesn't include the partition key (created_at)
ALTER TABLE events ADD CONSTRAINT events_id_unique UNIQUE (id);
-- ERROR: unique constraint on partitioned table must include all partitioning columns

-- This SUCCEEDS: partition key included
ALTER TABLE events ADD CONSTRAINT events_id_created_unique UNIQUE (id, created_at);