Summary: Heroku vs Hasura vs Firebase vs your own VM
HEROKU HASURA FIREBASE YOUR OWN VM
BaaS
( Backend as a Service )
components
In-built APIs No BaaS Auth, Data, Filestore & Notify Auth, Data (+ realtime) and more No BaaS
Data APIs power No BaaS SQL power, bulk queries, Allows schema migrations Basic CRUD queries No BaaS
Generating client code No BaaS Automatically generates copy pastable client code in diff languages Has code samples in diff languages No BaaS
Lines of code 200 (source: rails-heroku) 30 (source: hasura) 20 ( source: NA ) 200 (source: rails)
PaaS
( Platform as a Service )
components
One-click Deployment Yes, using git Yes, using gitAlready hosted No PaaS
Deploy custom code Supported technologies AnythingIn nodejs with restrictions on dependencies No PaaS
Access remote servicesUsing heroku-cli Using ssh tunnels No PaaS
SSL Manual Auto Auto No PaaS
Others
Use case specificity Stack specific proprietary buildpacks Application and stack specific Dockerfile based boilerplates NA NA
Architecture Can/must setup your own backend stack, infra is multi-tenant/hiddenComes with Postgres/k8s based backend stack; Infra is dedicated, customisable Stack is proprietary; infra is multi-tenant/hiddenCan/must setup your own backend stack; Dedicated, completely customisable infra
Lock-in Lock in at the platform and infra levelNo lock in at the database, platform or infra level Lock in at all levelsNo lock-in at all
Feature comparison: Firebase vs Hasura
FIREBASE HASURA
Data APIs
Querying Only simple queries Postgres allows complex queries essential for apps in production (eg: Analytics or BI queries)
Easy to learn data modelling (SQL and noSQL)Proprietary database, unintuitive Postgres supports relational modelling and JSON types
Schema management & migrationsCan only change the data from the client side Schema and data migrations captured declaratively in yaml files
Permissions Permissions can only capture rules based on the data within the current ‘path’ (node) Granular permissions based on the user-id in a row or relationships
Auth APIs
Auth middleware Extra code required if you want your service to check if a user is authenticated Custom APIs automatically use session tokens and user-id generated by the auth API
Custom auth Using firebase SDKs or manually creating and managing JWTsEasy to add through signup/login webhooks without worrying about session handling and edge-cases
Others
Filestore APIs Not possible to set custom permissions Easy to specify granular permissions for accessing files
Code generation from API console Does not expose APIs for all its features All features exposed as APIs, possible to generate copy pastable code in diff languages
Writing custom codeOnly in nodejs with restrictions on dependencies Write your custom APIs in any language or framework and deploy them with just a ‘git push’
Use-case specific NA hasura.io/hub is a collection of application and stack specific boilerplates
Architecture comparison: Firebase vs Hasura
FIREBASE HASURA
Stack
ExtensibilityCan only write custom code in nodejs with restrictions on dependencies Deploy custom APIs in any language/framework (uses Docker) or deploy your own Dockerfile or Docker image
Scalability Data locked into proprietary database, custom code written as (proprietary) Google cloud functions. Can’t optimise for scale Runs on Kubernetes and Docker and all your data is stored in a dedicated Postgres instance. All OSS, configurable
Workflow
Collaboration Not designed for collaborative workflows Everything is declarative, with git handling version control. Collaboration works as you would expect it to work with Git
Local development Local dev is difficult because custom code can only be written as Google Cloud functionsLocal dev is easy because you’re developing with a standard open-source framework/stack
Testing/managing multiple environments Manage multiple environments for hosting easily using CLI. Does not handle schema changes, configuration changes or hosting/source code changes for your custom APIsAll your work (data modelling, migrations, configurations, source code) is present as files. You can deploy to any environment easily
Feature comparison: Heroku vs Hasura
HEROKU HASURA
BaaS
In built APIs NA Built-in APIs on Postgres for Data, Auth, Filestore and Notify
Deployment experience
Git push to deploy Git push to deploy code Git push to deploy code, configuration (like subdomain or route changes), multiple microservices
Files/Storage Restricted to Heroku’s add-on ecosystem of stateful services Can deploy services that use volumes/disks, including stateful services
Deploying custom code Restricted to using proprietary buildpacks Uses Docker - Either select from a list of boilerplate Dockerfiles or use a Docker Image directly
TCP services Restricted to Heroku’s add-on ecosystem for TCP services Deploy any TCP service and expose them to the external world by creating a ‘load-balancer’
Others
Use-case specific Stack specific proprietary buildpacks Application and stack specific Dockerfile based boilerplates
SSL Manually upload SSL certificates for your custom domains Automatic SSL generation for custom domains
Architecture comparison: Heroku vs Hasura
HEROKU HASURA
Platform
Microservices vs apps Only allows you to deploy ‘apps’. Cannot implement microservices patterns like API gateways, etc Code runs as microservices on dedicated kubernetes cluster, accessible through an API gateway (if you choose to expose it)
CustomisabilityData stored on multi-tenant Postgres server, code runs as Dynos fronted by proprietary API router. Customisability limited to Heroku’s marketplace Data stored on dedicated Postgres instance, code runs as Docker containers with Kubernetes configuration, API gateway is a dedicated nginx + redis system. All OSS, all configurable as required
Infrastructure
Type Multi-tenant across all Heroku projects. Individual projects don't have the isolation or infra SLAs of dedicated VMs Kubernetes cluster running on a cluster of dedicated VMs, Better security (isolation) and infrastructure SLAs
Control Control only at the number of dynos (apps) levelControl underlying provider, region, config
Lock in - platform/infra
Migrating custom code Requires migrating procfiles/buildpacks for your custom code Requires no changes because of the use of Docker, Kubernetes
Migrating infra Migration to diff infra not possible, changing your region is a long and tedious processRequires no code change, frictionless