Nhost vs Supabase: Chọn Backend GraphQL Nào Tối Ưu?

query GetPost($id: uuid!) {
  posts_by_pk(id: $id) {
    title
    comments {
      content
      user {
        display_name
      }
    }
  }
}

const { data } = await supabase
  .from('posts')
  .select('title, comments(content, user:users(display_name))')
  .eq('id', id)

{
  "id": { "_eq": "X-Hasura-User-Id" }
}

Điểm mạnh: permission nằm ngay tầng GraphQL, áp đều cho query, mutation, subscription. Frontend gọi API trực tiếp mà vẫn an toàn nếu permission đúng.

Supabase: RLS mạnh ở database

Supabase dùng PostgreSQL Row Level Security. Policy nằm trong database:

create policy "Users can update own profile"
on profiles
for update
using (auth.uid() = id);

Ưu điểm: bảo mật sâu, ngay tầng database. REST, Realtime, RPC đều chịu policy. Đây là mô hình rất mạnh và đúng Postgres.

Nhược điểm với GraphQL: bạn cần suy nghĩ bằng SQL/RLS nhiều hơn bằng GraphQL permission. Với team frontend-heavy, Hasura permission thường dễ nhìn hơn. Với team backend/SQL-heavy, Supabase RLS rõ và bền hơn.

Realtime và subscription

Nhost

Hasura hỗ trợ GraphQL subscriptions. Nếu app dùng GraphQL realtime, Nhost rất tự nhiên:

subscription WatchMessages($roomId: uuid!) {
  messages(where: { room_id: { _eq: $roomId } }) {
    id
    content
    created_at
  }
}

Use case hợp:

– Chat.
– Dashboard live.
– Collaboration.
– Notification.
– Task board.

Subscription dùng cùng schema, same permission model. Developer không cần học API realtime riêng.

Supabase

Supabase Realtime lắng nghe thay đổi Postgres: insert, update, delete. Client subscribe theo channel và filter.

Use case tốt:

– Presence.
– Broadcast.
– Database change feed.
– Live UI.

Nhưng nếu team muốn GraphQL subscription chuẩn, Supabase không phải lựa chọn tối ưu. Bạn có thể xây lớp GraphQL riêng, nhưng khi đó mất lợi thế BaaS nhanh.

Custom business logic

Nhost

Nhost có serverless functions. Bạn dùng khi logic không nên nằm trong CRUD GraphQL:

– Thanh toán.
– Webhook Stripe.
– Gửi email.
– Xử lý file.
– Tích hợp API bên thứ ba.
– Job side-effect.

Ngoài ra Hasura có:

– Actions: custom GraphQL mutation/query gọi HTTP service.
– Event Triggers: nghe DB event, gọi webhook.
– Remote Schemas: gộp GraphQL service ngoài.

Đây là bộ công cụ rất hợp kiến trúc GraphQL composition. Bạn giữ CRUD trong Hasura, logic đặc thù trong functions/actions.

Supabase

Supabase có Edge Functions chạy trên Deno. Rất tốt cho:

– API tùy chỉnh.
– Webhook.
– Auth hook.
– Scheduled task.
– Tích hợp AI/API ngoài.

Ngoài ra Postgres function/RPC rất mạnh. Bạn có thể đẩy logic xuống database:

create function publish_post(post_id uuid)
returns void
language plpgsql
as $$
begin
  update posts set status = 'published' where id = post_id;
end;
$$;

Supabase hợp nếu team thích SQL function, trigger, view, materialized view. Nhost hợp nếu team muốn logic xoay quanh GraphQL và HTTP functions.

Developer experience

Nhost DX

Nhost DX tốt nhất khi:

– Frontend dùng GraphQL.
– Team dùng codegen type từ GraphQL schema.
– App cần nested query phức tạp.
– Permission cần nhìn theo role/schema.
– Realtime cần subscription.

Stack thường thấy:

– Next.js/React/Vue.
– Apollo Client/urql.
– GraphQL Code Generator.
– Nhost SDK.
– Hasura Console.

Điểm cần học: Hasura metadata, permission, relationship, action/event trigger.

Supabase DX

Supabase DX rất mạnh nhờ:

– Dashboard trực quan.
– Docs nhiều.
– SDK thân thiện.
– Local dev ổn.
– SQL editor tiện.
– Cộng đồng lớn.
– Ví dụ nhiều cho Next.js, SvelteKit, Flutter, React Native.

Stack thường thấy:

– Next.js + Supabase Auth.
– Supabase client query builder.
– RLS policy.
– Edge Functions.
– Storage + Realtime.

Nếu team không bắt buộc GraphQL, Supabase thường cho tốc độ ban đầu rất cao.

Hiệu năng và khả năng mở rộng

Cả hai đều dựa trên PostgreSQL, nên hiệu năng phụ thuộc nhiều vào:

– Index.
– Query shape.
– Permission policy.
– Connection pooling.
– Database size.
– N+1 query.
– Realtime load.
– Function cold start.

Nhost với Hasura

Hasura compile GraphQL thành SQL hiệu quả, nhưng query GraphQL quá sâu có thể nặng. Cần kiểm soát:

– Depth limit.
– Allow list/persisted queries.
– Index đúng cột filter.
– Pagination bắt buộc.
– Permission condition không quá phức tạp.

Supabase với Postgres/RLS

Supabase hiệu năng tốt nếu SQL tốt. Nhưng RLS policy phức tạp có thể làm query chậm. Cần:

– Index cột dùng trong policy.
– Tránh policy gọi function đắt.
– Dùng EXPLAIN ANALYZE.
– Tách read model bằng view/materialized view nếu cần.

Về scale, cả hai cần tư duy database nghiêm túc khi app lớn. BaaS không thay thế thiết kế dữ liệu tốt.

Chi phí và lock-in

Nhost

Lock-in chính:

– Hasura metadata.
– Permission model.
– Nhost Auth claims.
– Functions/deployment config.

Nhưng nền tảng open-source, Postgres vẫn portable. Nếu rời Nhost, bạn có thể tự host Postgres + Hasura + auth/storage tương đương, nhưng migration không miễn phí về công sức.

Supabase

Lock-in chính:

– Supabase Auth.
– Storage API.
– Edge Functions.
– Realtime.
– RLS policy vẫn là Postgres chuẩn hơn.

Supabase cũng open-source, dễ self-host hơn về mặt tư duy Postgres. Nhưng tự host đầy đủ Supabase stack vẫn cần vận hành nhiều service.

So chi phí, không nên chỉ nhìn giá tháng đầu. Hãy tính:

– Thời gian dev.
– Thời gian vận hành.
– Chi phí rewrite.
– Khả năng debug.
– Năng lực team.

Khi nào chọn Nhost?

Chọn Nhost nếu:

– GraphQL là API chính.
– App cần GraphQL subscription.
– Team muốn auto-generated GraphQL CRUD.
– Frontend cần type-safe GraphQL workflow.
– Permission theo role/row/column cần rõ trong GraphQL layer.
– Muốn dùng Hasura Actions/Event Triggers/Remote Schemas.
– Dự án có nhiều nested query và relationship.

Ví dụ hợp:

– SaaS dashboard realtime.
– Collaboration app.
– Internal tool nhiều role.
– Marketplace cần query linh hoạt.
– App mobile/web dùng chung GraphQL API.

Khi nào chọn Supabase?

Chọn Supabase nếu:

– GraphQL không phải yêu cầu cứng.
– Team giỏi SQL/Postgres.
– Muốn dùng REST/RPC/client SDK nhanh.
– Auth, storage, realtime, edge function cần setup nhanh.
– RLS ở database là ưu tiên.
– Cần cộng đồng lớn, ví dụ nhiều, docs dày.
– Muốn logic gần Postgres hơn GraphQL.

Ví dụ hợp:

– MVP nhanh.
– SaaS CRUD thông thường.
– App content/community.
– Product cần auth + storage + realtime cơ bản.
– Team nhỏ muốn ít học thêm Hasura.

Bảng so sánh nhanh

| Tiêu chí | Nhost | Supabase |
|—|—|—|
| Triết lý | GraphQL-first | Postgres-first |
| API chính | Hasura GraphQL | REST/PostgREST, SDK |
| GraphQL | Rất mạnh | Có, không phải trọng tâm |
| Permission | Hasura role/row/column | PostgreSQL RLS |
| Realtime | GraphQL subscriptions | Realtime channels/change feed |
| Custom logic | Functions, Actions, Triggers | Edge Functions, RPC, triggers |
| Team hợp | GraphQL/frontend-heavy | SQL/backend-heavy |
| Learning curve | Hasura metadata | RLS/Postgres policy |
| Lock-in | Hasura/Nhost model | Supabase services |
| Best fit | GraphQL app nghiêm túc | Full backend nhanh, Postgres mạnh |

Kết luận thực tế

Nếu dự án của bạn chọn GraphQL làm hợp đồng API chính, Nhost thường là lựa chọn đúng hơn. Hasura mang lại GraphQL CRUD, relationship, permission, subscription, metadata workflow rất mạnh. Team frontend có thể đi nhanh với query đúng nhu cầu UI và type generation rõ.

Nếu dự án của bạn chỉ “muốn có GraphQL nếu tiện”, còn trọng tâm là Postgres, auth, storage, realtime, function, SDK dễ dùng, Supabase thực tế hơn. Supabase cho tốc độ cao, cộng đồng lớn, RLS mạnh, trải nghiệm phát triển mượt.

Quy tắc ngắn:

– GraphQL là trung tâm → chọn Nhost.
– Postgres là trung tâm → chọn Supabase.
– Team frontend thích GraphQL → Nhost.
– Team backend thích SQL/RLS → Supabase.
– Cần GraphQL subscription chuẩn → Nhost.
– Cần MVP nhanh, không khóa vào GraphQL → Supabase.

Chọn nền tảng không chỉ vì tính năng. Chọn vì mô hình tư duy khớp team. Khi tư duy khớp, backend nhỏ, code sạch, roadmap nhanh. Khi tư duy lệch, công cụ tốt cũng thành gánh nặng.