#planetscale

When the Postgres query planner goes rogue — PlanetScale

Một vấn đề nghiêm trọng xảy ra khi PostgreSQL planner từ chối sử dụng index và tạo ra một truy vấn tốn tài nguyên. Nguyên nhân kỹ thuật là do planner đánh giá sai lựa chọn index, dẫn đến việc quét toàn bộ bảng thay vì sử dụng index đã có. Hệ quả là truy vấn tiêu thụ tới 20 GB dữ liệu và làm tăng tải hệ thống lên 300%. Bài viết từ PlanetScale chia sẻ cách họ sử dụng traffic control để ngăn chặn các truy vấn độc hại này, một bài học hữu ích về quản lý hiệu năng database trong các hệ thống lớn.

Bài viết giải thích cách kiểm soát truy vấn Postgres gặp sự cố khi trình lập kế hoạch bỏ qua chỉ mục, giúp lập trình viên hiểu và tránh các vấn đề hiệu năng nghiêm trọng.

Rule Builders for Every Validation Rule in Laravel 13.36

Laravel 13.36 adds Rule:: builders for the remaining validation rules, DB::olap() for PlanetScale, and an option to reset sticky connections between queue jobs.

Changelog IRL @ PlanetScale (Sept 17, 2026)

Vào ngày 17 tháng 9 năm 2026, chương trình Changelog sẽ tổ chức sự kiện tại trụ sở PlanetScale ở San Francisco với các bài nói chuyện ngắn và thảo luận về AI, công cụ lập trình và dự án đang phát triển. Sự kiện sẽ gồm ba phiên trò chuyện 20 phút với khách mời đặc biệt, có thời gian đặt câu hỏi và giao lưu. Đây là cơ hội quý giá để các lập trình viên tiếp cận kiến thức mới về công nghệ đang định hình tương lai ngành. Nếu bạn quan tâm đến AI và developer tools, đây chắc chắn là sự kiện không nên bỏ qua.

Sự kiện này mang đến cơ hội độc đào cho lập trình viên được trò chuyện trực tiếp với các chuyên gia hàng đầu về AI và công cụ phát triển.

What is a Neki router? — PlanetScale

Neki router là giải pháp cho hệ thống database sharding trong môi trường có nhiều shard, giúp ứng dụng kết nối với một database duy nhất thông qua giao thức Postgres. Công nghệ này đóng vai trò trung gian, tự động lên kế hoạch và điều phối các truy vấn phân tán đằng sau. Hệ quả là ứng dụng không cần xử lý logic phức tạp để quản lý nhiều shard, đồng thời vẫn duy trì được hiệu năng cao. Điều đáng học là cách Neki router abstract hóa sự phức tạp của sharding, tương tự như cách PlanetScale đã tối ưu hóa trải nghiệm database cho nhà phát triển.

Bài này giúp lập trình viên hiểu cách Neki router quản lý truy vấn Postgres trên cơ sở dữ liệu phân mảnh.

Deadlocks and downtime — PlanetScale

Deadlocks xảy ra khi các transaction chặn lẫn nhau, có thể leo thang thành downtime nghiêm trọng. Nguyên nhân kỹ thuật bao gồm việc các transaction giữ lock trên các resource khác nhau và chờ đợi lẫn nhau mà không cơ chế giải quyết. Hệ quả là ứng dụng PlanetScale có thể gặp sự cố đáng kể, đặc biệt với số lượng transaction lớn và xung đột phức tạp. Để giảm thiểu deadlock, bạn có thể tối ưu query và implement retry logic hiệu quả. Bài viết cũng giới thiệu Traffic Control như giải pháp bảo vệ database khỏi chính ứng dụng của bạn.

Bài viết này giúp lập trình viên hiểu cách phòng chống và xử lý deadlock để bảo vệ hệ thống database khỏi thời gian chết.

The lifecycle of a sharded Postgres query — PlanetScale

Follow a SQL query through the router, across four Postgres shards, and back.

What is a data topology? — PlanetScale

A data topology describes the sharding scheme a Neki router uses to map logical PostgreSQL tables to physical shards and route queries.

How one connection kills a database — PlanetScale

Một connection đơn lẻ có thể làm nghẽn toàn bộ database trên PlanetScale nếu không được quản lý đúng cách. Nguyên nhân kỹ thuật là do cơ chế lock trong MySQL mà PlanetScale dựa vào, nơi một connection bị lỗi hoặc chậm trễ có thể giữ lock trên các bảng và tài nguyên hệ thống. Hệ quả là toàn bộ các query khác bị block, dẫn đến downtime và performance giảm sút đáng kể. Giải pháp là dùng live connection management trong PlanetScale CLI và dashboard để monitor và terminate các connection bị stuck, một bài học quan trọng về tầm quan trọng của việc quản lý connection pool trong hệ thống phân tán.

PlanetScale giúp quản lý kết nối trực tiếp để giải quyết các kết nối bị kẹt trong database của bạn.

Problem solving with PlanetScale Insights — PlanetScale

The best way for you and your agents to see how your database actually performs in production.

The history of Postgres sharding — PlanetScale

Why has it taken so long to get good Postgres sharding? The last 20 years are the answer.

Poisoned Postgres connection pools — PlanetScale

An engineer's worst nightmare is waking up to a seemingly read-only database with no clear issue in sight. Let's dig into why this happens, and how AI can help solve it.

Egress problems and where to find them — PlanetScale

Reducing the size and frequency of requests to your database has the double benefit of making your applications faster and cheaper.

Problems with large tables in Postgres — PlanetScale

Postgres presents pretty predictable performance problems when dealing with large tables. Sharding solves this.

Transparency in benchmarking — PlanetScale

Bối cảnh benchmark database thiếu minh bạch khiến khách hàng khó ra quyết định và không thúc đẩy các nhà cung cấp cải tiến sản phẩm. Nguyên nhân kỹ thuật là do nhiều benchmark sử dụng environment kiểm soát chặt chẽ, không phản ánh thực tế sử dụng. Hệ quả là cộng đồng developer không có căn cứ khách quan để so sánh hiệu năng giữa các công nghệ database như PlanetScale, Neon hay Supabase. Điều đáng học là việc benchmark minh bạch với môi trường thực tế sẽ giúp cả người dùng và nhà cung cấp cùng tiến bộ, ví dụ như cách PlanetScale công khai benchmark test với dataset 10GB và query mẫu thực tế.

Bài viết này giúp lập trình viên hiểu cách đánh giá cơ sở dữ liệu một cách minh bạch để đưa ra quyết định kỹ thuật đúng đắn và thúc đẩy các nhà cung cấp cải tiến sản phẩm.

See what your database is doing right now with Connections — PlanetScale

Connections lets you monitor and manage all active connections to Postgres and Vitess databases. See active sessions, identify locking patterns, and keep debugging even when normal application connections are exhausted.

Introducing Neki — PlanetScale

PlanetScale vừa tung ra Neki, phiên bản sharded của Postgres đang ở trạng thái platform preview. Công nghệ này sử dụng kiến trúc sharding để giải quyết vấn đề hiệu năng khi scale Postgres lên quy mô lớn. Neki có thể xử lý hàng triệu request mỗi giây nhờ cơ chế phân mảnh tự động và API tương thích với Postgres truyền thống. Lập trình viên nên thử nghiệm giải pháp này nếu đang gặp thách thức về performance khi scale database, đặc biệt với các ứng dụng có traffic cao.

Bài giới thiệu Neki của PlanetScale giúp lập trình viên tìm hiểu giải pháp Postgres được shard sẵn sàng cho nhu cầu mở rộng quy mô ứng dụng.

Postgres backups under the hood — PlanetScale

Backup trong Postgres hoạt động thông qua cơ chế Point-in-Time Recovery (PITR) kết hợp WAL (Write-Ahead Logging). Toàn bộ thay đổi dữ liệu được ghi vào WAL trước khi ghi vào database chính, cho phép khôi phục lại trạng thái tại bất kỳ thời điểm nào. Một bản snapshot toàn bộ dữ liệu được định kỳ tạo ra (ví dụ: pg_dump), kết hợp với WAL files để hoàn chỉnh quy trình backup. Hệ thống này đảm bảo Recovery Point Objective (RPO) gần như bằng không nếu WAL được sao lưu đủ thường xuyên. Lập trình viên nên tìm hiểu sâu hơn về cách quản lý WAL retention và pg_basebackup để tối ưu hóa backup strategy.

Bài viết này giải thích cách hoạt động của sao lưu Postgres giúp lập trình viên hiểu rõ hơn về bảo vệ dữ liệu.

On benchmarking — PlanetScale

Benchmarking is hard. Done wrong it is very misleading, and unfortunately it is frequently done wrong. Let's explore how not to make silly mistakes.

One Postgres cluster, many apps — PlanetScale

Yo, I heard you liked databases, so we put logical databases in your database cluster so you can database while you database