Với một website WordPress thì dùng MySQL của hosting là đúng. Nhưng với database cho web app do AI viết (Next.js, Supabase, Prisma), chạy ở nơi khác hosting, thì thường nên đặt PostgreSQL ngay cạnh app trên VPS, hoặc dùng dịch vụ PostgreSQL có quản lý nếu bạn không có người biết Linux. Lý do: database của hosting sinh ra để phục vụ website chạy cùng máy, còn kết nối từ xa vào nó vừa chậm, vừa dễ lỗi, vừa mở thêm một cửa cho bot dò mật khẩu.
Tôi là Lê Minh Công, nhiều năm triển khai web app và tự động hoá cho doanh nghiệp vừa và nhỏ. Tình huống tôi gặp khá thường xuyên: chủ cửa hàng hoặc người tự làm app đã có sẵn gói hosting giá rẻ, và nghĩ «sẵn có database đó, tận dụng luôn cho đỡ tốn». Bài này giúp bạn tính cho đúng trước khi làm.
Database của hosting được làm ra cho ai?
Database của hosting dùng chung được làm cho website PHP + MySQL/MariaDB chạy cùng một máy, điển hình là WordPress. Nó không được thiết kế để làm kho dữ liệu cho một web app đặt ở nơi khác.
- Bạn tạo database bằng vài cú bấm trong cPanel, DirectAdmin hoặc Plesk, rồi quản lý bằng phpMyAdmin.
- Mặc định database chỉ nhận kết nối từ chính máy đó (
localhost). Website và database nằm cùng máy nên nhanh và an toàn. - Giá các gói phổ biến trong nước khoảng vài chục đến vài trăm nghìn đồng/tháng. Gói rẻ thường chỉ cho 1–2 database. Hãy kiểm tra trang chính thức của nhà cung cấp, thời điểm viết có thể khác lúc bạn đọc.
- Hosting có hỗ trợ PostgreSQL không? Theo quan sát của tôi, gần như không gói phổ thông nào có. Bạn nên kiểm tra trang chính thức của nhà cung cấp mình định mua, vì tình hình thay đổi theo thời điểm.
Vậy hosting có dùng làm database cho web app Next.js được không? Về kỹ thuật là được trong một số trường hợp, nhưng như các phần sau sẽ thấy, nó vướng nhiều thứ.
Web app chạy nơi khác kết nối database từ xa vào hosting như thế nào?
Muốn kết nối database từ xa vào hosting, bạn phải bật Remote MySQL (có nơi gọi là Remote Database Access) trong panel, khai báo các IP được phép và chấp nhận cổng 3306 mở ra internet.
Vấn đề nằm ở khâu khai IP. Các nền tảng như Vercel chạy app trên nhiều máy và đổi IP liên tục, nên người ta hay khai % (cho phép mọi IP). Lúc đó cổng database của bạn đứng trần trụi trên internet, bot quét cổng sẽ thử dò mật khẩu suốt ngày đêm. Ngoài ra, một số nhà cung cấp chặn hẳn kết nối từ xa ở gói rẻ, bạn mua xong mới biết.
Hãy hình dung đường đi của một câu truy vấn: người dùng mở trình duyệt, gửi yêu cầu tới app đặt ở nước ngoài, app gửi truy vấn qua internet về database ở Việt Nam, database trả kết quả ngược lại, app dựng trang rồi mới trả về trình duyệt. Một chuyến đi và về, mỗi lần truy vấn.
Vậy bật Remote MySQL có an toàn không? An toàn hơn nếu bạn khai đúng IP cố định của nơi chạy app và dùng mật khẩu dài, riêng cho từng database. Còn khai % thì rủi ro cao. Nếu app của bạn nằm ở nền tảng đổi IP liên tục, bạn gần như không có cách khai đúng.
Ba cái vấp khi dùng database hosting cho web app
1. Độ trễ: mỗi truy vấn đều phải đi một vòng
Mỗi truy vấn đi qua internet mất vài chục đến vài trăm mili-giây. Một trang gọi 10–20 truy vấn (danh sách đơn, thông tin khách, tồn kho, quyền người dùng…) sẽ chậm thấy rõ. Ví dụ minh hoạ: 15 truy vấn, mỗi truy vấn 100 mili-giây thì riêng phần chờ database đã là khoảng 1,5 giây, trước khi tính thời gian dựng trang.
2. Giới hạn số kết nối mỗi user
Database hosting thường đặt max_user_connections rất thấp. App serverless lại hay mở nhiều kết nối cùng lúc khi có nhiều người truy cập. Kết quả là lỗi too many connections đúng lúc đông khách nhất, ví dụ giờ cao điểm của một cửa hàng đang chạy khuyến mãi.
3. Code AI viết mặc định cho PostgreSQL
Next.js + Drizzle/Prisma, hay Supabase, thường mặc định là PostgreSQL. Đổi sang MySQL nghĩa là sửa schema, bỏ kiểu JSONB và mảng, và mất Row Level Security (RLS, cơ chế chặn quyền xem dữ liệu đến từng dòng). Nếu cần nhắc lại khái niệm, xem bài PostgreSQL là gì và khác MySQL ở đâu.
Vì sao web app trên Vercel nối database của hosting bị chậm hoặc lỗi kết nối? Thường là tổng hợp của cả ba điều trên: khoảng cách xa, số kết nối bị chặn thấp và IP đổi liên tục.
PostgreSQL trên VPS: app và database kết nối với nhau ra sao?
Cách làm phổ biến là chạy app và PostgreSQL bằng Docker trên cùng một VPS, hai bên nói chuyện qua mạng nội bộ. Độ trễ dưới 1 mili-giây, và cổng database không phải mở ra internet.
- Chuỗi kết nối có dạng
postgres://…@postgres:5432/…, trong đópostgreslà tên dịch vụ database trong mạng nội bộ của Docker. - Muốn xem dữ liệu bằng DBeaver hoặc pgAdmin từ máy mình, bạn không mở cổng ra ngoài mà đi qua SSH tunnel (đường hầm SSH) bằng khoá SSH.
- Bên ngoài chỉ thấy app, không thấy database.
Trải nghiệm thật: hệ thống của 5F Edu đang chạy web app, PostgreSQL và các tác vụ nền trên cùng một VPS theo đúng cách này. Tôi quản trị database qua SSH tunnel chứ không mở cổng database ra ngoài. (Tôi không nêu IP, cổng hay khoá thật ở đây, và bạn cũng không nên chia sẻ chúng ở bất cứ đâu.)
Chi phí khi có 1 app, 3 app, 10 app
Hosting rẻ hơn khi bạn chỉ có một website hoặc app nhỏ. Từ app thứ 2–3 trở đi, VPS thường có lợi hơn vì giá cố định theo tháng mà chạy được nhiều thứ.
| Tiêu chí | Hosting + MySQL | VPS + PostgreSQL trong Docker |
|---|---|---|
| 1 website/app nhỏ | Rẻ nhất, gần như không phải làm gì | Đắt hơn, phải tự cài đặt |
| 3 app | Thường phải mua thêm gói hoặc nâng gói vì giới hạn số website, số database | Một VPS đủ chạy, giá cố định |
| 10 app | Tốn nhiều gói riêng, dễ rối | Tuỳ cấu hình và tải, thường vẫn chạy được trên một hoặc vài VPS |
| Tiến trình nền, cron dài | Gần như không chạy được | Chạy được |
| Kết nối của app tới database | Từ xa (nếu app ở nơi khác) | Nội bộ, dưới 1 mili-giây |
| Việc bảo trì | Nhà cung cấp lo phần lớn | Bạn tự lo |
Giá cụ thể mỗi nơi mỗi khác, và thay đổi theo thời gian. Hãy kiểm tra trang chính thức ở thời điểm bạn mua. Nếu muốn tính cấu hình, xem bài Deploy web app xong thì app và dữ liệu nằm ở đâu.
Một VPS chạy được bao nhiêu database? Không có con số cố định. Một server PostgreSQL có thể chứa nhiều database, giới hạn thực tế là RAM, CPU, ổ đĩa và mức tải của từng app. Bạn nên bắt đầu với vài app nhỏ, theo dõi mức dùng RAM và ổ đĩa rồi mới thêm.
Tự giữ database thì phải trả cái giá nào?
Cái giá là trách nhiệm: khi tự giữ database, bạn là người duy nhất lo cho nó. Hosting thắng ở sự nhàn, còn VPS thắng ở sự linh hoạt và hiệu năng.
- Tự cập nhật bản vá cho hệ điều hành và PostgreSQL.
- Tự sao lưu và thử khôi phục. Bản sao lưu chưa từng khôi phục thử thì chưa chắc dùng được.
- Tự theo dõi ổ đĩa đầy.
- Tự chịu khi VPS sập.
Các công cụ như Dokploy hoặc Coolify đỡ cho bạn phần triển khai và sao lưu. Nếu không có ai biết Linux trong đội, dịch vụ PostgreSQL có quản lý (Supabase, Neon) là đường giữa: bạn không phải lo máy chủ, đổi lại trả phí theo gói và dữ liệu nằm ở nhà cung cấp.
Khi nào hosting vẫn là lựa chọn đúng?
Hosting vẫn đúng khi website của bạn là WordPress, landing page hoặc blog, và khi bạn muốn nhàn.
- App PHP + MySQL nhỏ chạy ngay trên hosting đó: database vẫn là
localhost, không có độ trễ hay vấn đề mở cổng. - Bạn cần người khác lo cập nhật và sao lưu thay mình.
Ví dụ: một tiệm may đo cần website giới thiệu và form đặt lịch thì WordPress trên hosting là đủ, không cần dựng PostgreSQL.
Chọn nhanh theo tình huống
| Tình huống | Nên chọn |
|---|---|
| Website WordPress | Hosting |
| Web app AI đầu tiên, chưa có người kỹ thuật | Supabase hoặc Neon |
| Có từ 2–3 app, cần cron/tác vụ nền, muốn chi phí cố định | VPS + PostgreSQL trong Docker |
| Đang nối database hosting từ xa và thấy chậm hoặc lỗi kết nối | Dấu hiệu nên chuyển |
Tóm tắt và bước tiếp theo
Database của hosting dành cho website chạy cùng máy. Kết nối từ xa vào nó gây ba vấn đề: chậm, bị giới hạn kết nối và lệch kiểu dữ liệu với code AI viết. PostgreSQL cạnh app trên VPS nhanh hơn và kín hơn nhưng bạn phải tự sao lưu, vá lỗi. Dịch vụ có quản lý là lựa chọn giữa hai bên.
- Liệt kê app bạn đang có và database mỗi app dùng.
- Kiểm tra app nào đang nối database hosting từ xa. Nếu có khai
%, hãy xử lý trước. - Thử đo thời gian tải trang chạm database, rồi quyết định chuyển hay giữ.
Nếu bạn đang tự làm web app bằng AI, bộ tài liệu miễn phí tại tài liệu vibe coding có thể giúp ích cho các bước tiếp theo.
Xem thêm
Câu hỏi thường gặp
›Hosting có dùng làm database cho web app Next.js được không?
Được trong một số trường hợp nhưng không phải lựa chọn tốt. Hosting thường chỉ có MySQL/MariaDB, trong khi code AI viết cho Next.js hay dùng PostgreSQL, nên bạn phải sửa schema. Thêm vào đó, app đặt nơi khác phải bật kết nối từ xa, vừa chậm vừa tăng rủi ro bảo mật.
›Bật Remote MySQL có an toàn không?
Chỉ tương đối an toàn nếu bạn khai đúng IP cố định của nơi chạy app và dùng mật khẩu mạnh. Nếu khai «%» (mọi IP) vì nền tảng đổi IP liên tục thì cổng 3306 mở ra internet cho bot dò mật khẩu. Trường hợp đó nên cân nhắc đặt database cạnh app.
›Vì sao web app trên Vercel nối database của hosting bị chậm hoặc lỗi kết nối?
Do mỗi truy vấn phải đi qua internet đến database ở nơi khác nên có độ trễ, và một trang gọi nhiều truy vấn sẽ cộng dồn. App serverless còn mở nhiều kết nối cùng lúc nên dễ chạm giới hạn max_user_connections, sinh lỗi too many connections. IP đổi liên tục cũng khiến việc khai IP được phép khó đúng.
›Một VPS chạy được bao nhiêu database?
Không có con số cố định. Một server PostgreSQL có thể chứa nhiều database, giới hạn thực tế là RAM, CPU, ổ đĩa và tải của từng app. Hãy bắt đầu với vài app nhỏ và theo dõi mức dùng tài nguyên trước khi thêm.
Tác giả
Chuyên gia chuyển đổi số · Đại diện 5F Edu
Hơn 8 năm triển khai và tư vấn chuyển đổi số cho doanh nghiệp vừa và nhỏ: chuẩn hoá quy trình, xây phần mềm quản lý bằng AppSheet và web app, tự động hoá bằng N8N. Người làm kênh YouTube Nghiện AppSheet.
