Hasura developers build and maintain the instant GraphQL API layer that automatically generates queries, mutations, and subscriptions from PostgreSQL (and other database) schema definitions — configuring table permissions that restrict row and column access by authenticated role, wiring remote schemas and REST endpoints into the unified GraphQL gateway through schema stitching, and implementing event triggers and scheduled triggers that fire webhooks to external services when database rows change, enabling event-driven backend architectures without writing boilerplate resolver code. At remote-first technology companies, they serve as the backend and API engineers who replace hand-rolled GraphQL resolvers and REST endpoints with Hasura's declarative metadata layer where database relationships, authorization rules, and API composition are configured through the Hasura Console or infrastructure-as-code metadata YAML — reducing the time from database schema to production API from weeks to hours.
What Hasura developers do
Hasura developers configure database connections — connecting Hasura to PostgreSQL (primary), and additional sources including MySQL, MS SQL Server, BigQuery, and MongoDB through the Data Sources console or pg_add_source metadata API; track tables and views — using pg_track_table or the console to expose database tables as GraphQL types, making them queryable through the auto-generated schema with filtering (where), sorting (order_by), pagination (limit/offset/cursor), and aggregation queries; define relationships — configuring array_relationship and object_relationship between tables using foreign key constraints so that query { orders { id user { name } items { product { title } } } } traverses joins in a single GraphQL request; configure permissions — defining role-based row-level security with check expressions (JSON predicates evaluated against row data and session variables) and filter expressions restricting which rows a role can read/insert/update/delete, and column-level permissions controlling which fields each role can access; implement session variables — using JWT claims (Hasura reads x-hasura-role, x-hasura-user-id, and custom claims from the JWT) or webhook-based authentication to inject user context into permission checks, enabling filter: { user_id: { _eq: "X-Hasura-User-Id" } } rules that automatically scope data to the authenticated user; add remote schemas — connecting external GraphQL APIs (custom Node.js resolvers, AWS AppSync, third-party APIs) through add_remote_schema and merging them into the Hasura gateway so clients query all APIs through a single endpoint; configure REST endpoints — wrapping named GraphQL queries as REST endpoints through the REST Endpoints console for clients that prefer REST, with path parameters mapped to GraphQL variables; implement event triggers — using pg_create_event_trigger to fire webhooks when table rows are inserted, updated, or deleted, with retry configuration and delivery logs for reliable event-driven side effects (send email on user creation, sync to CRM on order completion); implement scheduled triggers — using create_cron_trigger for recurring webhook invocations on a cron schedule (daily reports, subscription renewals, cache warming); write actions — defining custom mutations and queries backed by REST or GraphQL webhook handlers for business logic that cannot be expressed as database operations (payment processing, external API calls), with type definitions that integrate the action's input/output types into the Hasura schema; configure remote joins — using create_remote_relationship to join database data with remote schema data in a single query (fetch user from local DB, join their Stripe subscription from a remote schema); manage metadata as code — exporting Hasura metadata as YAML with hasura metadata export and applying it with hasura metadata apply for GitOps-managed deployments where schema and permissions are version-controlled; and handle migrations — using hasura migrate create and hasura migrate apply to manage database schema migrations alongside metadata changes in a single workflow.
Key skills for Hasura developers
- Schema: track tables/views; auto-generated CRUD; relationships (array/object); computed fields
- Permissions: role-based access; row-level check/filter; column permissions; session variables
- Authentication: JWT claims (x-hasura-*); webhook auth; admin secret; role inheritance
- Real-time: GraphQL subscriptions; live queries; streaming subscriptions; polling fallback
- Remote schemas: add_remote_schema; schema stitching; remote join; field merging
- Actions: custom queries/mutations; REST/GraphQL handlers; type definitions; async actions
- Event triggers: pg_create_event_trigger; INSERT/UPDATE/DELETE; retry config; delivery logs
- Scheduled triggers: cron trigger; one-off scheduled events; webhook payload
- Metadata-as-code: hasura CLI; metadata export/apply; migrations; config.yaml; version control
- Performance: connection pooling (PgBouncer); query caching; index recommendations; N+1 analysis
Salary expectations for remote Hasura developers
Remote Hasura developers earn $105,000–$168,000 total compensation. Base salaries range from $88,000–$138,000, with equity at technology companies where the speed of shipping new API features, the correctness of authorization rules that prevent data leakage between tenants, and the reliability of event-driven workflows triggered by database changes directly determine product velocity and security posture. Hasura developers with multi-role permission model design for SaaS platforms with tenant isolation requirements, remote schema federation integrating Hasura with custom GraphQL microservices, action and event trigger architecture replacing custom API server code with Hasura's declarative event layer, and demonstrated development velocity improvements where Hasura reduced the time from schema change to production API from days to hours command the strongest premiums. Those with Hasura combined with deep PostgreSQL performance tuning and schema design expertise earn toward the top of the range.
Career progression for Hasura developers
The path from Hasura developer leads to senior backend engineer (broader scope including custom GraphQL API development, database design, and service architecture beyond Hasura's generated layer), API platform engineer (owning the API gateway, schema federation, and developer experience for engineering organizations using Hasura as part of a larger API ecosystem), or full-stack architect (designing the complete frontend-to-database data access layer where Hasura's real-time subscriptions power reactive UIs). Some Hasura developers specialize into authorization architecture, designing the session variable injection pipelines, JWT claim structures, and row-level permission expressions that implement complex multi-tenant access control. Others transition into the broader GraphQL federation space, using Hasura as one subgraph in an Apollo Federation or Grafbase mesh alongside custom resolvers. Hasura developers who contribute to the community — writing permission pattern libraries, building Hasura migration tools, or documenting multi-database federation patterns — contribute to one of the most widely adopted instant GraphQL platforms.
Remote work considerations for Hasura developers
Building Hasura-based API infrastructure for distributed engineering teams requires permission model conventions, action and event trigger ownership standards, and metadata management practices that prevent distributed engineers from creating permissive allow all permissions that expose entire tables to unauthenticated roles, writing actions that bypass Hasura's permission system by calling the admin endpoint directly from frontend code, or committing metadata conflicts when multiple engineers modify Hasura configurations simultaneously without a metadata-as-code review workflow. Hasura developers at remote companies establish the permission authoring standard — requiring that every tracked table has explicit permissions for every role that accesses it, with no fallback to the admin role for non-admin operations — because distributed engineers who skip permission configuration for "internal" tables leave those tables accessible to any authenticated user, creating data leakage when a new role is added; enforce the admin secret boundary — documenting that the Hasura admin secret must never appear in client-side code or unauthenticated API calls, and that the x-hasura-admin-secret header is restricted to server-to-server communication — because distributed engineers who embed admin secrets in mobile apps or frontend environment variables expose unrestricted database access; establish metadata-as-code workflow — requiring that all Hasura configuration changes (table tracking, relationships, permissions, event triggers) go through hasura metadata export → Git PR → hasura metadata apply — because distributed engineers who make console changes without exporting metadata create configuration drift between environments that produces bugs in staging but not development; and document the N+1 relationship pattern — requiring that all GraphQL queries with relationship traversal use batched dataloader patterns or Hasura's native join execution rather than per-row relationship resolution — because distributed engineers who write queries like { users { orders { items } } } without understanding Hasura's join strategy can trigger unbounded database fan-out on large datasets.
Top industries hiring remote Hasura developers
- SaaS product companies where Hasura's instant CRUD API and row-level permissions eliminate the boilerplate backend code for multi-tenant data models, enabling small engineering teams to ship new data-driven features without writing resolver code for every new table
- Healthcare and life sciences organizations where Hasura's role-based column permissions implement HIPAA-compliant data access controls that restrict which roles can read sensitive patient fields, with audit logging through event triggers capturing all data access events
- E-commerce and marketplace platforms where Hasura's real-time subscriptions power live inventory counts, order status updates, and chat interfaces, and event triggers send order events to fulfillment services and payment processors on row insertion
- Financial services companies where Hasura's PostgreSQL-native permission model with session variable injection implements account-scoped data access at the API layer, preventing horizontal privilege escalation between customer accounts
- Developer tooling and internal tool companies using Hasura as the backend for React-based admin panels and internal dashboards, where Hasura's auto-generated API eliminates the need for custom API endpoints for every data management operation
Interview preparation for Hasura developer roles
Expect permission model questions: how would you configure Hasura permissions so that a user can only read their own orders — what the filter expression with X-Hasura-User-Id session variable looks like and where the session variable comes from. Relationship questions ask how you'd configure Hasura to return a user's orders and each order's items in a single GraphQL query — what array and object relationships look like and how Hasura translates them to SQL joins. Actions questions ask when you'd use a Hasura Action instead of a direct table mutation — what business logic can't be expressed as a database operation (payment processing, external API calls) and what the action type definition and webhook handler look like. Event trigger questions ask how you'd automatically send a welcome email when a new user row is inserted — what the event trigger configuration and webhook payload look like. Remote schema questions ask how you'd add a custom GraphQL API (a Node.js service) to the Hasura schema so clients can query both in a single request — what add_remote_schema and remote joins look like. Subscription questions ask how you'd implement a real-time order status tracker that updates the UI when the order row changes — what a Hasura subscription query looks like on the client. Metadata-as-code questions ask how you'd manage Hasura configuration changes across development, staging, and production environments using version control.
Tools and technologies for Hasura developers
Core: Hasura GraphQL Engine 2.x; Hasura Cloud; Hasura CE (self-hosted); Hasura Console; Hasura CLI. Schema: track_table; track_function; computed fields; table relationships; enum tables; custom type definitions. Permissions: create_insert/select/update/delete_permission; role; check (insert constraint); filter (select constraint); columns; set (column presets); backend_only. Authentication: JWT mode (HS256/RS256); x-hasura-role; x-hasura-user-id; x-hasura-allowed-roles; webhook auth; unauthenticated role; admin secret. Relationships: array_relationship; object_relationship; foreign keys; manual relationships; remote joins (create_remote_relationship). Remote schemas: add_remote_schema; schema stitching; field merging; remote schema permissions. Actions: create_action; synchronous; asynchronous; input types; output types; action relationships; REST/GraphQL handler. Event triggers: pg_create_event_trigger; INSERT/UPDATE/DELETE; session variables; delivery logs; retry config; transform. Scheduled triggers: create_cron_trigger; one-off events; cron schedule; payload. Real-time: GraphQL subscriptions; live queries (polling interval); streaming subscriptions (cursor-based). Metadata: hasura metadata export/apply/diff; hasura migrate create/apply; config.yaml; databases.yaml; tables.yaml; actions.yaml. Performance: PgBouncer connection pooling; query caching (Redis); streaming subscriptions; EXPLAIN analysis; pg_dump for large schema debugging. Hasura DDN (v3): supergraph; subgraph; connector; data connector spec; new metadata format. Alternatives: PostGraphile (PostgreSQL-native, schema-first); Supabase (PostgreSQL + auto API + auth); Prisma (ORM, not auto-API); WunderGraph (API gateway); custom Apollo Server.
Global remote opportunities for Hasura developers
Hasura developer expertise is in strong and growing demand globally, with Hasura's position as the leading instant GraphQL engine — with over 30,000 GitHub stars, Hasura Cloud serving thousands of companies, and adoption at organizations including Airbus, Atlassian, and numerous high-growth SaaS companies for their primary data API layer — creating consistent demand for engineers who understand both Hasura's auto-generation model and the permission architecture that makes it production-safe. US-based Hasura developers are in demand at SaaS companies building multi-tenant data products, healthcare and fintech organizations with strict access control requirements, and startups using Hasura to ship data APIs faster than custom backend development allows. EMEA-based Hasura developers are well-positioned given Hasura's strong European startup adoption — European SaaS companies and digital product agencies have adopted Hasura as the backend-for-frontend layer that eliminates custom API code, and Hasura's GDPR-compliance features make it attractive in the European market. Hasura's continued development — Hasura DDN (v3) with the supergraph model, improved multi-database federation, and the data connector specification — ensures sustained demand as instant GraphQL API generation becomes a standard pattern for rapid product development.
Frequently asked questions
How does Hasura's permission model work and how do session variables enable row-level security? Hasura's permissions are role-based, where each role has separate insert, select, update, and delete permissions on each table. The session variables mechanism bridges authentication and authorization: when a request arrives at Hasura, the JWT or webhook auth mode extracts claims from the token and makes them available as session variables (x-hasura-user-id, x-hasura-role, custom claims). Permissions reference session variables in their check and filter expressions — for example, a select permission with filter: { user_id: { _eq: "X-Hasura-User-Id" } } causes Hasura to append a WHERE user_id = '<token-user-id>' clause to every query made by that role, so users only ever see their own rows regardless of the GraphQL query's where argument. Column permissions control which fields are included — a customer role might have select permission on orders but only on id, status, and created_at columns, not internal_notes. check expressions (for insert/update) validate that data being written meets conditions: { user_id: { _eq: "X-Hasura-User-Id" } } prevents users from inserting rows with a different user_id. This declarative permission model replaces resolver-level authorization code, but requires careful design — missing a permission leaves a table either inaccessible or using a less-restrictive inherited rule.
When should you use Hasura Actions versus Event Triggers, and how do they differ? Actions and event triggers both involve webhooks, but serve different purposes. Actions extend Hasura's GraphQL schema with custom business logic: an action defines a new mutation or query type in the Hasura schema (createPaymentIntent(amount: Int!): PaymentResult!) that calls a webhook handler (Node.js, Python, any HTTP server) when invoked — the action is triggered by a client GraphQL request, executes synchronously or asynchronously, and returns a typed response that integrates into the Hasura schema. Use actions for: operations requiring external API calls (Stripe, SendGrid), complex business logic that transforms or validates data before writing, and any operation that shouldn't be a direct database write. Event triggers are database-change-driven: Hasura creates a PostgreSQL trigger on the table and fires a webhook when rows are inserted, updated, or deleted — the trigger is asynchronous, retried on failure, and delivers a payload with old and new row data. Use event triggers for: side effects that should happen after a database change regardless of which operation caused it (sync to CRM when user is created, send notification when order status changes), event sourcing patterns, and audit logging. The key distinction: actions are request-driven (client explicitly calls them), event triggers are data-driven (any change to the table fires them).
What is the difference between Hasura's live queries and streaming subscriptions? Hasura supports two real-time subscription mechanisms. Live queries (polling-based): Hasura runs the query against the database at a configurable polling interval (default 1 second), diffs the result against the last delivered payload, and pushes only if the data changed. The client receives the full current dataset on each update. This is simple to use but creates constant database load proportional to the number of live subscribers and the polling interval. Streaming subscriptions (cursor-based, Hasura 2.7+): instead of polling the full dataset, streaming subscriptions use a cursor (typically id or created_at) and query for rows WHERE cursor_field > last_cursor — delivering only new rows appended after the subscription started. This is efficient for append-only tables (event logs, messages, activity feeds) because database load is proportional to new data volume rather than subscriber count. When to use each: live queries for small, frequently-changing datasets where the client needs the full current state (live scores, order status); streaming subscriptions for high-volume append-only data where the client needs to receive new events without re-fetching the full history (chat messages, audit logs, event feeds). For very high concurrency, Hasura's multiplexed subscriptions batch similar queries together, executing one database query for multiple subscribers with similar parameters.