Migration snapshot
ActivePlatform
a Hasura
Hasura v2 engine is Apache 2.0 and stable. v3/DDN (Data Delivery Network) engine is also Apache 2.0 (rewritten in Rust, GA 2024–2025), but the DDN CLI, web console, and LSP are proprietary — community members on github.com/hasura/graphql-engine/discussions/#10556 document that v3's build/metadata workflow is effectively cloud-tied. GitHub repo actively updated 2026.
Typical timeline
6–10 weeks
Typical cost
$13K–$25K (agency, fixed)
Why teams leave a Hasura
Teams migrate from Hasura not because data is trapped — your database is yours throughout — but because the operational and licensing picture changed between v2 and v3, and GraphQL abstraction overhead may exceed its value for simpler workloads.
v3/DDN proprietary tooling lock-in
Even though the v3 engine is Apache 2.0, the DDN CLI, web console, and LSP are not open source. Teams on v3 Cloud face a vendor dependency on Hasura's managed tooling that didn't exist with v2. Community threads on GitHub (discussion #10556) document the effective cloud tie.
Hasura Cloud pricing escalates with enterprise features
SSO, response caching, observability, and rate limiting are gated to Business/Enterprise tiers. For teams that grew into these needs, the cost can exceed what a REST API layer on Supabase ($25/mo Pro) would require.
v2 to v3 is a rewrite, not an upgrade
The metadata format, connector model, and deployment pattern all changed between versions. Teams on v2 cannot trivially upgrade to v3 — it's effectively a new architecture. This makes Hasura's own upgrade path a migration risk.
Supergraph complexity exceeds single-app needs
v3/DDN federation metadata and connector config are designed for enterprise data supergraphs across dozens of data sources. A team running a single Postgres-backed application carries operational overhead built for a much larger use case.
GraphQL overhead for simple CRUD
Teams with straightforward CRUD + auth often find that an ORM (Drizzle or Prisma) plus Next.js API Routes replaces 90% of what Hasura provides — without the running container, metadata management, and permission layer to maintain.
What can you actually take with you?
Hasura sits over your own database — your data is never locked in. Metadata (API definition, permissions, triggers) exports cleanly from v2 via CLI. The migration is purely an API-layer swap with no data movement required.
| Asset | Can you export it? | How | Notes |
|---|---|---|---|
| Data | Yes | Hasura sits over your own Postgres/MySQL/MongoDB/etc. — SQL dump or managed DB backup at any time; no Hasura involvement needed | No vendor data lock-in of any kind; your database credentials and data are entirely independent of Hasura |
| Code / API Definition | Yes | v2: `hasura metadata export` produces full API definition as YAML/JSON — tracked tables, relationships, permissions, actions, event triggers; v3/DDN: YAML metadata format differs from v2; CLI tool is proprietary | v2 metadata is portable documentation, not executable code — it serves as the blueprint for rebuilding endpoints; v3 requires re-generating connector config |
| Design/UI | No | n/a — Hasura is a pure API layer with no UI | Your frontend application is separate code you own; Hasura's console is the platform's admin UI |
| Logic/Workflows | Partial | Actions (custom GraphQL mutations pointing to REST handlers) and Event Triggers are defined in metadata (exportable); the actual handler functions live in your own code outside Hasura | Handler code is fully yours and portable; integration points (Hasura→handler URLs) change but the business logic does not |
| Users & Auth | Yes | Hasura delegates auth to your own JWT provider or auth webhook — no Hasura password store; user data lives entirely in your own database or auth service (Supabase Auth, Clerk, etc.) | No password migration needed; auth is already external to Hasura; this is one of the cleanest auth migration stories in the backend space |
Swipe the table sideways to see the full breakdown.
Where each piece moves in code
Hasura migration is an API-layer swap — the underlying PostgreSQL database is untouched; the target stack is Next.js (App Router) + Drizzle ORM + Supabase (for auth, RLS, and optional auto-generated REST/GraphQL).
a Hasura
Hasura tracked tables + auto-generated GraphQL
In code
Next.js API Routes with Drizzle/Prisma querying the same PostgreSQL DB
Or keep GraphQL with graphql-yoga running on a Next.js Route Handler
a Hasura
Hasura Actions (custom GraphQL mutations → REST handlers)
In code
Next.js API Route Handlers (app/api/[route]/route.ts)
Handler code already lives outside Hasura; update the API contract, not the business logic
a Hasura
Hasura Event Triggers (database events → HTTP)
In code
Supabase database webhooks or pg_notify + custom listener
Supabase database webhooks fire on INSERT/UPDATE/DELETE to any HTTP endpoint
a Hasura
Hasura Scheduled Triggers
In code
Supabase pg_cron or Vercel Cron Jobs
pg_cron runs SQL or calls functions on schedule; Vercel Cron triggers serverless functions
a Hasura
Hasura row/column-level permissions
In code
PostgreSQL RLS policies + Supabase Auth JWT claims
The most complex translation — each Hasura permission rule becomes a PostgreSQL RLS policy; test each one
a Hasura
Hasura Remote Schema (federated GraphQL from external service)
In code
Apollo Federation or a separate Next.js API Route proxying the external service
Remote schemas with simple pass-through often simplify to a direct API Route call
a Hasura
Hasura GraphQL subscriptions (realtime)
In code
Supabase Realtime channels (WebSockets) or pg_listen + server-sent events
Supabase Realtime is the closest managed equivalent; architecture differs but outcomes are similar
a Hasura
Your underlying data source (Postgres/MySQL)
In code
Keep as-is — no data migration required
Only the API layer changes; the database credentials, schema, and data are unchanged
The migration roadmap
Because Hasura doesn't hold your data, the migration is entirely an API-layer rebuild. Start with a metadata export to have the full API definition, then work through permissions and event triggers before touching the database.
Phase 1: Audit and metadata export
1 week- Run `hasura metadata export` to capture the complete API definition as portable YAML
- Identify Hasura version (v2 vs v3/DDN) — migration path and complexity differ significantly
- Inventory all Actions and their handler service URLs — locate the external business logic code
- List all Event Triggers and Scheduled Triggers with their target URLs and business purpose
- Document all client-side GraphQL queries and subscriptions, especially realtime subscriptions
Watch out: v3/DDN metadata format is not compatible with v2 CLI export; if on v3, re-generating the connector config is part of scope
Phase 2: API design decision
1 week- Decide: keep GraphQL (graphql-yoga on Next.js) or migrate to REST (Drizzle/Prisma + API Routes)
- Map each Hasura tracked table to a corresponding API Route or Supabase auto-generated endpoint
- Document all Hasura permission rules — table/column/row level — as a planning spreadsheet
- Confirm which Remote Schemas are in use and plan their replacement (direct API Route or Apollo Federation)
Phase 3: Permission translation to PostgreSQL RLS
2 weeks- Translate each Hasura table permission to a PostgreSQL RLS policy (INSERT/SELECT/UPDATE/DELETE per role)
- Configure Supabase Auth JWT claims to pass role/user context into RLS policies
- Test each RLS policy with sample queries as different user roles before going live
- Map Hasura column-level permissions to column-level grants in PostgreSQL
Watch out: Permission translation is the most complex technical step — intricate Hasura rules may require PostgreSQL policy expertise
Phase 4: Action handlers and event/schedule migration
1–2 weeks- Update Action handler code (already yours) to be called directly by API Routes — remove Hasura intermediary
- Replace Hasura Event Triggers with Supabase database webhooks (Settings → Database → Webhooks)
- Migrate Scheduled Triggers to Supabase pg_cron or Vercel Cron; verify schedule expressions
- Replace Hasura GraphQL subscription clients with Supabase Realtime channel subscriptions
Phase 5: Cutover
1 week- Run new API layer in parallel with Hasura — point a staging environment at the new stack
- Update all client GraphQL/REST URLs to the new Next.js API endpoints
- Run integration tests against both environments; verify RLS policies match Hasura permission behavior
- DNS/config switch; decommission Hasura container/cloud subscription
Watch out: GraphQL subscription clients need updated connection URLs and potentially updated channel subscription syntax
Three ways to migrate — honestly
Every path has a real trade-off. Here is what each costs, how long it takes, and where it bites.
DIY with AI tools
$0–$500 + time
3–6 months part-time
Fits
Engineers comfortable with PostgreSQL RLS and TypeScript who have a v2 installation, a small number of tracked tables, and no complex event trigger chains
Risks
Permission translation is the hardest part — incorrect RLS policies create data access gaps that are easy to miss in testing; subscriptions need careful Supabase Realtime replacement
Freelancer
$4K–$10K
4–8 weeks
Fits
Teams with a v2 Hasura install, moderate complexity (20–40 tracked tables, a handful of Actions), and a clear GraphQL vs REST decision already made
Risks
Freelancers may not have deep PostgreSQL RLS experience — validate their policy work with integration tests; v3/DDN migrations add complexity that may exceed initial estimates
Agency (RapidDev)
Done-for-you$13K–$25K fixed
6–10 weeks
Fits
Teams on Hasura Cloud v2 or v3/DDN with production workloads, complex permission rules, or Active subscriptions requiring Supabase Realtime parity; fixed price covers full API layer replacement
Risks
Minimal — fixed-price scope includes permission audit, RLS translation, event trigger migration, and parallel-run validation. Free scoping call at rapidevelopers.com.
The real risks — and how to defuse them
v3/DDN metadata incompatibility
Mitigation: Determine your Hasura version before scoping; v2 migration is a clean API swap, v3 requires re-generating connector metadata. Don't assume v2 tooling applies to v3 installations.
Permission translation gaps — incorrect RLS policies create unintended data access
Mitigation: Build a permission mapping document before writing any RLS policies; test each policy against sample queries as multiple user roles; treat permissions as the highest-risk phase
GraphQL subscription clients break at cutover
Mitigation: Audit all client-side subscription queries before migration; Supabase Realtime channel API differs from Hasura subscription syntax — plan client-side updates; run parallel subscriptions during cutover window
Action handler integration points change
Mitigation: Handler code is yours and portable; maintain the same API signatures where possible to minimize client impact; update only the routing layer, not the business logic
Remote Schema dependencies not accounted for
Mitigation: Inventory all Remote Schema connections and client queries that use federated fields; plan direct API Route replacements for each before removing Hasura
Should you actually migrate?
Migrating is a real project. Sometimes staying is the right call — here is the honest split.
Stay if
- You have a large PostgreSQL database with complex relationships and Hasura's instant GraphQL genuinely saves weeks of API development — this is Hasura's strongest use case
- You are on v2 (Apache 2.0), self-hosting on Docker, and have no dependency on Hasura Cloud features — this is the maximum-ownership configuration with clean open-source licensing
- You need a data supergraph or federation layer across multiple data sources (Postgres + REST + external GraphQL) — Hasura v3/DDN is built for exactly this; the alternatives require significant custom orchestration
- Your team's primary bottleneck is rapid API surface generation from an existing complex schema — Hasura's introspection-based generation outpaces hand-written API Routes for large schemas
Migrate if
- You are on v3 Cloud and the proprietary DDN CLI/console creates an unacceptable vendor dependency — you want true open-source tooling for your infrastructure
- Hasura Cloud Business/Enterprise features (SSO, caching, observability, rate limiting) are driving cost above what Supabase Pro + custom middleware would cost
- Your GraphQL usage is basic CRUD + auth and an ORM (Drizzle/Prisma) plus Next.js API Routes would replace 90% of what Hasura provides without the operational overhead
- Your team struggles to maintain Hasura's metadata system and container operation — you'd prefer a managed Postgres API with less custom infrastructure
Our honest verdict
Hasura v2 self-hosted is among the cleanest exit stories in the backend space — your data is always yours, metadata exports verbatim. Migration is justified primarily when v3/DDN proprietary tooling creates lock-in, or when GraphQL abstraction complexity outweighs its value for your specific workload.
Do this today: pre-migration checklist
Whatever path you choose, protect yourself first. Work through this before you touch a line of code.
Run `hasura metadata export` today and commit the YAML to version control
This is your complete API definition — tracked tables, relationships, permissions, actions, event triggers — and the blueprint for rebuilding outside Hasura
Identify your exact Hasura version (v2 vs v3/DDN) before any planning
Migration path and scope differ significantly; v2 is a clean API-layer swap, v3 requires re-generating connector metadata and may involve proprietary tooling constraints
Locate and document all Action handler services with their source code repositories
Action handler code lives outside Hasura and is fully portable — confirming you have access is the first step; missing source code would require a rewrite
Inventory all Event Triggers and Scheduled Triggers with their target URLs and trigger conditions
These become Supabase database webhooks or pg_cron jobs; a complete inventory sizes this phase accurately before scoping
Audit all client-side GraphQL subscriptions across your frontend codebase
Realtime subscriptions are the hardest client-side change — Supabase Realtime channel API differs from Hasura subscription syntax; know the scope before cutover
Map every Hasura permission rule to its PostgreSQL RLS equivalent in a planning document
Permission translation is the most complex technical phase; doing the mapping on paper before writing RLS policies prevents access gaps in production
Confirm your underlying database connection credentials are independently stored
Your data source stays in place; you need direct DB access for the new stack before removing Hasura from the connection chain
Frequently asked questions
Can I export my Hasura data?
Yes — and this is Hasura's best-in-class story. Hasura sits over your own database (Postgres, MySQL, MongoDB, etc.) and never holds your data. You can take a standard SQL dump or managed backup at any time, with no Hasura involvement. Data lock-in is zero.
Can I export my Hasura metadata and API definition?
Yes, for v2: run `hasura metadata export` and you get your complete API definition as YAML — every tracked table, relationship, permission rule, action, event trigger, and scheduled trigger. This is not executable code but it is a complete, portable blueprint. For v3/DDN, the metadata format differs and the DDN CLI is proprietary, so export mechanics are more complex.
How long does a Hasura migration take?
Typically 6–10 weeks with a team. The data never moves, so the timeline is driven by API surface size, permission complexity, and how many realtime subscriptions need Supabase Realtime replacements. A small app with 10–15 tracked tables and minimal Actions can complete in 4 weeks; a complex supergraph with 50+ tracked tables and intricate permission rules takes the full 10 weeks.
What happens to my users and passwords when I migrate from Hasura?
Nothing changes — Hasura delegates auth entirely to your own provider (JWT/webhook). User accounts and passwords live in your auth service (Supabase Auth, Clerk, Auth0, your own database), not in Hasura. This is one of the cleanest auth migration stories: there is no user data to export from Hasura because Hasura never stored it.
Is Hasura shutting down?
No. Hasura is an active company with v2 (Apache 2.0) stable and v3/DDN (Rust engine, also Apache 2.0) in GA. The medium urgency in this guide reflects the v3/DDN proprietary tooling concern (DDN CLI, console, and LSP are not open source), not any platform shutdown risk.
What is the difference between migrating from Hasura v2 vs v3/DDN?
v2 migration is a clean API-layer swap: export YAML metadata, translate permissions to RLS, rebuild event/scheduled triggers, update client URLs. v3/DDN migration is more complex because the metadata format changed and the DDN CLI is proprietary — you need to re-generate connector config and cannot reuse v2 metadata tooling directly. Always identify your version before scoping.
Do I need to move my database when leaving Hasura?
No. This is the key insight: Hasura is an API layer over your database, not a database itself. Your PostgreSQL (or MySQL, etc.) stays exactly where it is. You replace the Hasura container with Next.js API Routes and Drizzle/Prisma, but the underlying data source is untouched.
How much does a Hasura migration cost with an agency?
RapidDev offers fixed-price Hasura migrations at $13K–$25K depending on complexity — number of tracked tables, permission rules, Actions, and subscriptions. The scope covers full API-layer replacement, RLS policy translation, event trigger migration, and a parallel-run validation period. Book a free scoping call at rapidevelopers.com to get an exact estimate.
We migrate no-code apps to production code
- Fixed price — $13K–$25K (agency, fixed)
- No data loss, no downtime
- You own 100% of the code
30-min call. Quote within 48 hours.