· neon / planetscale / postgres

Neon vs PlanetScale — Serverless Postgres vs serverless MySQL

Neon thắng cho solo developer: free tier, Postgres đầy đủ, branching tức thì. PlanetScale: NVMe, quản trị schema — bỏ free tier từ 4/2024.

Bởi

2.743 từ · 14 phút đọc

Nếu bạn là developer solo hoặc team giai đoạn đầu, hãy chọn Neon. Bạn được 0.5 GB và 100 compute-unit-hours miễn phí, Postgres thực sự, và instant data branch tích hợp ngon với Vercel preview deployment. PlanetScale bỏ free tier từ tháng 4/2024. Mức giá thấp nhất hiện tại là $5/tháng — không có gì sai nếu bạn sẵn sàng trả tiền, nhưng điều đó có nghĩa là hai sản phẩm này không còn cạnh tranh cho cùng một nhóm người dùng nữa.

Dành cho ai

Developers đang chọn giữa serverless Postgres và serverless MySQL (hay nay là Postgres) cho một dự án mới. Nếu bạn đang migrate một ứng dụng MySQL quy mô lớn, bài viết này sẽ giúp bạn hiểu rõ điểm mạnh của PlanetScale — nhưng phần so sánh free tier sẽ không liên quan đến bạn.

Những gì chúng tôi so sánh

Neon — serverless Postgres với compute và storage tách biệt. Kiểm tra dựa trên free tier và Launch plan hiện tại tính đến tháng 6/2026. Kiến trúc: Safekeepers (Paxos WAL consensus), Pageserver (on-demand page reconstruction từ object storage), stateless compute. Mã nguồn mở (AGPLv3/Apache 2.0).

PlanetScale — ban đầu là nền tảng MySQL trên Vitess, hiện đã có thêm Postgres (GA ngày 22/9/2025). Kiểm tra dựa trên pricing và tài liệu hiện tại tính đến tháng 6/2026. Kiến trúc: hạ tầng always-on với NVMe SSD gắn trực tiếp, Postgres operator độc quyền, PgBouncer proxy.

Đây là so sánh tài liệu và pricing, không phải benchmark. Những con số xuất hiện trong bài đều có ghi rõ nguồn. Nếu bạn cần bối cảnh rộng hơn về sự khác biệt giữa hai hệ cơ sở dữ liệu, xem Postgres vs MySQL 2026.

Nhận định nhanh

NeonPlanetScale
Free tier✅ 0.5 GB / 100 CU-hours/tháng❌ Không có (bỏ từ tháng 4/2024)
BranchingFull data clone (copy-on-write, instant)Schema-only mặc định; quy trình Deploy Request
Cold start300–800 ms (scale-to-zero mặc định)Không có — always-on

Neon

Kiến trúc

Neon tách compute và storage hoàn toàn. Khi Postgres compute của bạn scale về không sau năm phút không hoạt động, dữ liệu không đi đâu cả — nó nằm trong object storage (tương thích S3), được Pageserver dựng lại theo yêu cầu.

Đường ghi đi qua Safekeepers: một cụm node dùng Paxos consensus để commit WAL trước khi transaction trả về. Cơ chế này thay thế fsync trên một đĩa đơn bằng một network quorum. Pageserver replay lại WAL đó để dựng lại bất kỳ page nào tại bất kỳ thời điểm nào trong lịch sử — đây là lý do branching có thể tức thì: tạo một branch là thao tác metadata, không phải copy dữ liệu.

Giá

PlanComputeStorageBranches
Free100 CU-hours/tháng (auto-scale đến 2 CU)0.5 GB10
Launch$0.106/CU-hour (đến 16 CU)$0.35/GB-tháng10 included
Scale$0.222/CU-hour (đến 56 CU, 224 GB RAM)$0.35/GB-tháng25 included

Cần hiểu rõ một chút về compute-unit pricing: mức tối thiểu là 0.25 CU (0.25 vCPU, 1 GB RAM). Nếu app của bạn idle phần lớn thời gian trong tháng và scale về không, hóa đơn chỉ tính những giờ thực sự hoạt động. Plan free sẽ tạm dừng compute khi chạm bất kỳ giới hạn nào — và không tự khởi động lại cho đến chu kỳ billing tiếp theo.

Branch được tính phí khác với database gốc: các branch con dùng copy-on-write delta từ branch cha, nên một branch chưa diverge nhiều gần như không tốn gì. Branch vượt quá giới hạn plan tính thêm $1.50/branch-tháng.

Read replica được tính phí như một compute instance riêng biệt.

Branching

Branching là điểm khác biệt rõ ràng nhất của Neon. Vì mỗi branch là một bản clone theo thời điểm của toàn bộ lịch sử WAL, bạn có một bản sao đầy đủ dữ liệu production trong dev branch — tức thì, không cần copy vật lý. Bạn có thể:

  • Tạo một branch cho mỗi pull request và tự động xóa khi PR được đóng
  • Point-in-time restore bằng cách branch từ bất kỳ thời điểm nào trong cửa sổ lịch sử (6 giờ trên Free, 7 ngày trên Launch, 30 ngày trên Scale)
  • Chạy schema migration có tính phá hoại trên một branch có dữ liệu thực trước khi động vào production

Tích hợp với Vercel hoạt động theo cách này: mỗi preview deployment có branch Neon riêng với dữ liệu production. Khi PR merge, branch bị xóa. Quy trình đó ngay từ đầu đã hoạt động sẵn.

Cold start

Scale-to-zero bật mặc định. Sau năm phút không hoạt động, compute tạm dừng. Query tiếp theo sẽ đánh thức nó dậy, và thời gian đó mất 300–800 ms theo đo lường cộng đồng (tài liệu chính thức của Neon ghi “vài trăm milliseconds”).

Bạn có thể giảm thiểu điều này:

  • Paid plan có thể tắt scale-to-zero hoàn toàn (compute chỉ tạm dừng sau 7 ngày không hoạt động — về thực chất là always-on)
  • sslnegotiation=direct trong connection string tiết kiệm ~119 ms theo đo lường của Neon
  • PgBouncer ở transaction mode (built-in pooler của Neon) giữ connection ấm sau lần wake-up đầu tiên

Với hầu hết ứng dụng serverless, request đầu tiên sau một khoảng idle phải trả chi phí cold start, những request tiếp theo thì không. Điều đó có chấp nhận được hay không phụ thuộc hoàn toàn vào traffic pattern của bạn.

Connection pooling

Neon tích hợp sẵn PgBouncer ở transaction mode, truy cập qua một connection string pooled riêng. Nó hỗ trợ đến 10.000 client connection đồng thời bất kể max_connections của Postgres (dao động từ 104 trên 0.25 CU đến 4.000 trên instance lớn).

Transaction mode có giới hạn đã biết: LISTEN/NOTIFY, temp table và SQL-level prepared statement không hoạt động qua pooler. Dùng connection string trực tiếp cho migration, pg_dump, và analytics chạy lâu.

Neon cũng có serverless HTTP driver cho edge runtime (Cloudflare Workers, Vercel Edge Functions) không cần WebSocket.

PlanetScale

Kiến trúc

PlanetScale chạy trên hạ tầng always-on với NVMe SSD gắn trực tiếp. Không có scale-to-zero. Một production branch là 1 primary cộng 2 replica trải trên ba availability zone, với automatic failover.

PlanetScale xuất phát từ nền tảng Vitess (MySQL) — Vitess là lớp horizontal sharding đang vận hành MySQL của GitHub, Slack và YouTube ở quy mô lớn. Xuất thân đã được kiểm chứng trong production đó cho PlanetScale sự tự tin ở connection count cao và data volume lớn.

Sản phẩm Postgres (thông báo tháng 7/2025, GA ngày 22/9/2025) chạy Postgres operator độc quyền với PgBouncer. PlanetScale đang xây dựng một sharding engine tên Neki cho Postgres từ đầu (không phải fork của Vitess). Tại thời điểm viết bài, Neki vẫn đang phát triển và Postgres plan chạy trên mô hình single-node hoặc unsharded.

Giá

PlanGiáGhi chú
Free tier❌ Không cóBỏ từ ngày 8/4/2024
Postgres Single Node$5/thángNetwork-attached storage
Postgres Metal$50+/thángLocal NVMe, throughput cao hơn
Vitess PS-20~$59/tháng2 vCPU
Vitess PS-40~$99/tháng4 vCPU

Storage gồm 10 GB, sau đó $0.50/GB. Egress gồm 100 GB, sau đó $0.06/GB. Connection không tính phí.

Việc bỏ free tier xứng đáng có một đoạn riêng. Ngày 6/3/2024, PlanetScale ngừng nhận tạo database Hobby mới. Ngày 8/4/2024, họ xóa các database Hobby hiện có và yêu cầu migrate lên paid plan. Paid tier rẻ nhất lúc đó là $39/tháng (Scaler Pro). Với developer chạy side project ở $0, điều này có nghĩa là nhảy thẳng từ $0 lên $39/tháng. Công ty viện dẫn ưu tiên sinh lời và cắt giảm nhân sự (chủ yếu là Sales và Marketing). Làn sóng developer chuyển sang Neon, Turso và Supabase sau đó diễn ra nhanh chóng và ồ ạt.

Branching

Branching của PlanetScale là công cụ quản trị, không phải công cụ nhân bản dữ liệu.

MySQL (Vitess) — trưởng thành, tài liệu đầy đủ:

Development branch mặc định chỉ chứa schema. Không có dữ liệu production trong dev branch trừ khi bạn dùng Data Branching® (restore từ backup — tốn thêm chi phí và thao tác). Quy trình là:

  1. Tạo dev branch từ production
  2. Thực hiện thay đổi DDL trên dev branch
  3. Mở một Deploy Request — PlanetScale diff schema và hiển thị những gì được thêm hoặc xóa
  4. Peer-review diff, validate trên staging
  5. Thêm vào deploy queue — PlanetScale chạy migration non-blocking trên production bằng online DDL (dùng gh-ost nội bộ)

Mô hình này buộc bạn phải có kỷ luật: bạn không thể DDL trực tiếp trên protected production branch. Mọi thay đổi schema đều phải qua một queue được peer-review. Với team đã từng gặp sự cố production vì ALTER TABLE trực tiếp, đây là thứ thực sự có giá trị.

Postgres (mới hơn):

Quy trình Deploy Request đang được phát triển cho Postgres. Tài liệu và độ trưởng thành kém hơn hệ thống branching MySQL. Không có tương đương với instant full-data copy-on-write clone của Neon.

Cold start

Không có. PlanetScale chạy hạ tầng always-on. Bạn trả tiền dù database idle hay đang xử lý 1M QPS. Latency ổn định vì không có chu trình suspend/resume.

Hiệu năng

PlanetScale công bố benchmark tháng 9/2025 so sánh PlanetScale M-320 (4 vCPU, 32 GB RAM, NVMe) với Neon Scale 8cu (8 vCPU, 32 GB RAM, network storage):

BenchmarkPlanetScaleNeonChênh lệch
TPCC QPS (500 GB, 64 connections)~18.000~12.500+44%
OLTP Read QPS (300 GB)~33.000~27.000+22%
p99 latencyThấp hơnBiến động nhiều hơnPlanetScale

Lưu ý: đây là benchmark tự công bố bởi PlanetScale. Khoảng cách NVMe so với network storage là có thực — SSD gắn trực tiếp luôn vượt network-attached storage về throughput bền vững và p99 latency. Nhưng workload thực tế rất đa dạng, và cách thiết kế workload trong bất kỳ benchmark nào của vendor đều có lợi cho vendor đó. Con số từ bên thứ ba độc lập sẽ đáng tin cậy hơn.

So sánh trực tiếp

Triết lý branching

Đây là sự khác biệt thiết kế cơ bản nhất. Neon cho bạn dữ liệu production trong branch vì branching là một thao tác WAL replay — dữ liệu đến cùng miễn phí. Branching của PlanetScale được xây để quản trị schema, không phải nhân bản môi trường; để có dữ liệu trong branch cần thêm bước và chi phí.

Nếu bạn chạy preview deployment cần dữ liệu giống production để bắt được bug thực, Neon thắng không cần bàn. Nếu bạn quản lý một team đã từng có sự cố production do DDL không kiểm soát, quy trình Deploy Request của PlanetScale là thứ bạn cần — và online DDL migration non-blocking của nó là thứ bạn không muốn tự implement bằng pt-online-schema-change hay gh-ost.

Cold start

PlanetScale không có. Neon có theo mặc định và có thể loại bỏ trên paid plan bằng cách tắt scale-to-zero.

Với traffic production always-on, tắt scale-to-zero trên Neon (Launch hoặc Scale plan) và lập luận về cold start biến mất. Với dự án free tier, cold start là không thể tránh.

Connection pooling

Về cơ bản hòa nhau. Cả hai đều tích hợp sẵn pooler ở transaction mode. Cả hai đều có HTTP-based serverless driver cho edge runtime. Neon ghi nhận giới hạn 10.000 client connection qua PgBouncer; PlanetScale liệt kê connection là không tính phí.

Free tier

Neon thắng, không thể tranh luận. PlanetScale không có free tier. Với ai đang đánh giá cả hai sản phẩm với ngân sách $0, phần so sánh kết thúc tại đây.

Độ trưởng thành trong hệ sinh thái Postgres

Neon LÀ Postgres — tương thích hoàn toàn, đầy đủ extension, bất kỳ công cụ nào chạy được với Postgres chuẩn đều chạy được với Neon. Neon đã ở production từ năm 2021.

PlanetScale Postgres GA từ tháng 9/2025. Nó chạy Postgres 17 thực, nhưng trong môi trường managed với extension support hạn chế và tooling branching còn mới. Với Postgres-native workflow, Neon là lựa chọn an toàn hơn hiện tại.

Nếu Supabase cũng nằm trong danh sách cân nhắc, xem Neon vs Supabase — so sánh chi tiết hai giải pháp serverless Postgres phổ biến nhất.

Bảng quyết định theo use case

Chọn Neon nếu:

  • Bạn cần free tier cho prototyping, project mã nguồn mở, hay side project
  • Bạn dùng Vercel + Next.js và muốn per-PR preview database với dữ liệu thực
  • Bạn cần đầy đủ Postgres extension, pg_dump, hay bất kỳ công cụ Postgres chuẩn nào
  • Workload của bạn bursty hoặc idle phần lớn thời gian (PAYG billing có thể về $0)
  • Bạn thích hạ tầng mã nguồn mở

Chọn PlanetScale nếu:

  • Bạn có hạ tầng MySQL/Vitess hiện tại ở quy mô lớn và cần horizontal sharding
  • Quản trị schema change là yêu cầu bắt buộc (Deploy Request peer review + non-blocking DDL)
  • Bạn không thể chấp nhận bất kỳ cold-start latency nào và không muốn tự cấu hình always-on
  • Bạn đang chạy high-throughput MySQL workload mà lợi thế NVMe có tác động tích lũy
  • Bạn cần PCI DSS hoặc SOC 2 với single-tenant dedicated option
Tình huốngChọn
Next.js trên VercelNeon
Side project / prototypingNeon (free tier)
CI/CD preview database với dữ liệu thựcNeon
Startup hạn chế ngân sáchNeon
Postgres-first, tương thích tối đaNeon
Enterprise MySQL app quy mô lớnPlanetScale (Vitess)
Team cần quản trị schema changePlanetScale
Latency nhạy cảm, không chấp nhận cold startPlanetScale
High-throughput MySQL (tiềm năng 1M+ QPS)PlanetScale

Kết luận

Neon là lựa chọn mặc định đúng đắn cho hầu hết developers trong năm 2026. Free tier có thực (0.5 GB, 100 CU-hours), tương thích Postgres hoàn chỉnh, và mô hình branching thực sự hữu ích cho quy trình deployment hiện đại. Nếu bạn đang bắt đầu một dự án và không có lý do cụ thể phải trả tiền từ ngày đầu, hãy bắt đầu với Neon.

PlanetScale là lựa chọn xứng đáng nếu bạn cần những gì nó thực sự cung cấp: non-blocking schema migration với peer-reviewed Deploy Request, hạ tầng always-on không có cold start, và NVMe throughput ở đầu cao. Nó đã rời thị trường developer/free-tier từ tháng 4/2024 theo lựa chọn của chính mình. Điều đó biến nó thành một sản phẩm enterprise nghiêm túc — không phải một phiên bản kém hơn của Neon.

Cần xem thêm các lựa chọn? Dịch vụ host Postgres tốt nhất cho SaaS nhỏ so sánh Neon với Railway, Supabase và các nhà cung cấp khác.

Lưu ý

Sản phẩm PlanetScale Postgres mới khoảng 9 tháng (GA tháng 9/2025). Một số giới hạn chúng tôi ghi nhận cho Neon ngày nay — extension support, độ trưởng thành của branching — có thể đã được giải quyết khi bạn đọc bài này. Hãy kiểm tra tài liệu hiện tại.

Các con số benchmark trong phần hiệu năng đến từ benchmark tự công bố của PlanetScale. Hãy coi đó là ngưỡng sàn của lợi thế NVMe, không phải phép đo trung lập.

Bài viết này chứa referral link đến Neon (link /go/neon ở trên). Nếu bạn đăng ký và chi tiêu $20, toolchew nhận $20 — xem disclosure ở đầu trang.

Tài liệu tham khảo