Inside branch-based restores in Lakebase Postgres

Neon · 2026 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bài quảng bá của nhà cung cấp (Neon, nay gọi kiến trúc là "lakebase"). Phần so sánh với RDS và số liệu khảo sát là theo Neon; khảo sát chỉ 50 developer. Phần "agent dùng restore để undo" chỉ tóm tắt ngắn.

Bối cảnh

• Theo Neon, restore ở Postgres managed truyền thống chậm và càng chậm khi DB càng lớn. Failover sang replica giúp khi máy chết, nhưng không giúp khi lệnh ghi sai hay DROP TABLE đã sang cả standby: lúc đó vẫn phải restore.
• PITR truyền thống tới thời điểm T có ba bước:
  1. Dựng instance mới (compute và volume gắn liền, ít nhất bằng primary): instance lớn, volume EBS lớn thì mất lâu.
  2. Khôi phục snapshot từ S3 về volume. Theo Neon, RDS báo available trước khi nạp xong; block chưa có thì volume lấy từ S3 khi được chạm tới, latency chấp nhận được cho kiểm tra nội bộ nhưng không cho production. DB lớn mất hàng giờ.
  3. Replay WAL từ lúc snapshot tới T; snapshot cũ cộng ngày ghi nặng là rất nhiều WAL.
• Khảo sát của Neon (50 developer chạy Postgres production): 59% có sự cố production nghiêm trọng trong 12 tháng, 30% ngừng từ 3 giờ trở lên, chỉ 21% phục hồi dưới 60 phút.

Thay đổi chính (kiến trúc theo Neon)

• Compute và storage là hai hệ riêng, nối bằng WAL: compute chạy Postgres (SQL, plan, MVCC, lock, sinh WAL) nhưng không giữ bản bền của dữ liệu. Storage gồm ba phần: safekeeper nhận WAL (transaction bền khi một quorum safekeeper xác nhận); pageserver biến WAL thành page, dựng lại được bất kỳ page nào tại bất kỳ LSN nào; object storage giữ lịch sử bất biến dài hạn.
• Commit tách khỏi việc tạo page, và page cũ không bị ghi đè: lịch sử của DB là một dòng thời gian trỏ vào được, không phải một bản bị sửa liên tục.
• Restore = tạo branch tại một thời điểm: chọn thời điểm, có thể query thử để kiểm tra trước, control plane đổi thời điểm thành LSN, tạo branch và gắn compute riêng (connection string riêng). Branch không chép dữ liệu, chỉ trỏ vào các layer đã có; là thao tác metadata, nên thời gian không tăng theo kích thước (theo Neon, 100 TB nhanh như 10 GB, tính bằng giây).
• Hệ quả: restore đủ rẻ để thành một thao tác thường ngày, ví dụ nền tảng cho agent lưu checkpoint theo version code và "undo" cả schema lẫn dữ liệu.

Vì sao

• Theo Neon: chi phí restore truyền thống nằm ở chỗ compute và storage đóng gói chung, nên khôi phục là một việc di chuyển dữ liệu; khi lịch sử đã nằm ở object storage và trỏ vào được, khôi phục chỉ còn là đặt con trỏ.

Bài học cho SWE

• Replica bảo vệ khỏi máy chết, không bảo vệ khỏi lỗi logic; thời gian restore (RTO của PITR) là con số cần biết trước, và nó tăng theo kích thước DB trong kiến trúc gắn liền (Failover, replica và dự phòng dữ liệu).
• "Instance available" chưa phải "đã khôi phục xong": dữ liệu nạp lười từ object storage làm query đầu chậm.
• Khi storage giữ lịch sử bất biến và compute chỉ là người đọc, các thao tác vốn đắt (restore, clone, môi trường test) thành thao tác metadata (Tách compute khỏi storage).
• Kiểm tra trạng thái quá khứ trước khi cam kết restore giúp tránh restore sai thời điểm.

Liên quan

• Neon 2024 · Neon 2025 · Neon 2026 · PlanetScale 2026 · GitLab 2019
• Failover, replica và dự phòng dữ liệu · Tách compute khỏi storage