MVCC khiến mỗi UPDATE để lại một bản chết thay vì sửa tại chỗ — và chúng tích tụ thành bloat. Bài này đo thật trên pg-lab: một bảng chỉ có 1 hàng sống, sau 100.000 lần UPDATE phình từ 8 KB lên 3,5 MB. VACUUM dọn bản chết nhưng không trả đĩa; chỉ VACUUM FULL mới thu nhỏ file về 8 KB — nhưng khóa bảng độc quyền.
UPDATE trong PostgreSQL thường phải ghi lại mọi index — trừ khi là HOT update. Bài này đo thật trên pg-lab: với fillfactor mặc định 100, cập nhật cột không-index vẫn cho 0 HOT (trang đầy); hạ xuống 70 thì 4.368/10.000 là HOT (không ghi index). Và index-only scan cho Heap Fetches=0 khi query chỉ cần cột trong index, giảm I/O rõ rệt.
Độ bền của PostgreSQL đến từ WAL (write-ahead log): mọi thay đổi ghi vào log tuần tự và fsync xuống đĩa trước, trang dữ liệu ghi sau. Bài này đo thật trên pg-lab lượng WAL sinh ra: INSERT 10.000 hàng tạo 861 kB, COPY cùng dữ liệu chỉ 357 kB, UPDATE nặng nhất 1.645 kB, còn SELECT không sinh WAL. Kèm đánh đổi fsync và synchronous_commit.
Bạn không phải lúc nào cũng cần RabbitMQ hay SQS cho hàng đợi công việc — PostgreSQL làm được bằng SELECT FOR UPDATE SKIP LOCKED. Bài này đo thật trên pg-lab: 4 worker chạy song song vét sạch 300 job, chia đều 76/75/75/74, mỗi job xử lý đúng một lần, không trùng, không chờ khóa. Kèm advisory lock cho khóa mức ứng dụng.
Mười một bài, mười một phép đo thật bằng nhiều phiên psql đồng thời. Bài tổng kết này nối tất cả — MVCC, bốn mức cô lập, lost update, write skew, khóa hàng, deadlock, bloat, vacuum, HOT, WAL, SKIP LOCKED — thành một bảng số liệu và một checklist thực chiến: cần đảm bảo gì thì dùng gì, cạm bẫy đồng thời nào cần tránh, và vì sao mọi thứ bắt nguồn từ MVCC.
Metrics, logs, traces không phải ba cách làm cùng một việc — chúng trả lời ba câu hỏi khác nhau. Bài này đo thật trên Prometheus + Go app: cùng một endpoint, metric cho 90 thành công/11 lỗi (có vấn đề không?), log JSON cho chi tiết từng request (chuyện gì xảy ra?), và trace_id nối các bước lại (lỗi ở đâu?). Khi nào dùng cái nào và vì sao cần cả ba.