# Migrating Hasura to Code: The Complete Playbook (2026)

- Tool: No-Code to Code Migrations
- Last updated: July 2026

## TL;DR

Hasura is an active GraphQL layer over your own database. The key migration insight: your data never moves — only the API layer changes. v2 metadata exports cleanly via CLI. v3/DDN adds proprietary tooling lock-in despite an Apache 2.0 engine. Migrations take 6–10 weeks and cost $13K–$25K with an agency; the main work is translating Hasura permissions to PostgreSQL RLS policies.

## Platform status

- Status: active — 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.
- Migration urgency: medium
- Typical timeline: 6–10 weeks
- Typical cost: $13K–$25K (agency, fixed)

## Why migrate

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 you can export

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 | Exportable | How |
| --- | --- | --- |
| Data | yes | Hasura sits over your own Postgres/MySQL/MongoDB/etc. — SQL dump or managed DB backup at any time; no Hasura involvement needed |
| 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 |
| Design/UI | no | n/a — Hasura is a pure API layer with no 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 |
| 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.) |

## Stack mapping

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).

| Platform concept | Code equivalent |
| --- | --- |
| Hasura tracked tables + auto-generated GraphQL | Next.js API Routes with Drizzle/Prisma querying the same PostgreSQL DB |
| Hasura Actions (custom GraphQL mutations → REST handlers) | Next.js API Route Handlers (app/api/[route]/route.ts) |
| Hasura Event Triggers (database events → HTTP) | Supabase database webhooks or pg_notify + custom listener |
| Hasura Scheduled Triggers | Supabase pg_cron or Vercel Cron Jobs |
| Hasura row/column-level permissions | PostgreSQL RLS policies + Supabase Auth JWT claims |
| Hasura Remote Schema (federated GraphQL from external service) | Apollo Federation or a separate Next.js API Route proxying the external service |
| Hasura GraphQL subscriptions (realtime) | Supabase Realtime channels (WebSockets) or pg_listen + server-sent events |
| Your underlying data source (Postgres/MySQL) | Keep as-is — no data migration required |

## 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: 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: 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: 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: 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: 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

## Cost paths

| Path | Cost | Timeline | Fits |
| --- | --- | --- | --- |
| DIY with AI tools | $0–$500 + time | 3–6 months part-time | Engineers comfortable with PostgreSQL RLS and TypeScript who have a v2 installation, a small number of tracked tables, and no complex event trigger chains |
| Freelancer | $4K–$10K | 4–8 weeks | 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 |
| Agency (RapidDev) | $13K–$25K fixed | 6–10 weeks | 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 and mitigations

- **v3/DDN metadata incompatibility** — 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** — 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** — 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** — 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** — Inventory all Remote Schema connections and client queries that use federated fields; plan direct API Route replacements for each before removing Hasura

## Stay or go

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

Go 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

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.

## Migration checklist

- 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.

---

Source: https://www.rapidevelopers.com/no-code-to-code/how-to-migrate-hasura-project-to-code
© RapidDev — https://www.rapidevelopers.com/no-code-to-code/how-to-migrate-hasura-project-to-code