9 ms·

Show HN: Nhost – Open source Firebase alternative with GraphQL

210 points by elitan 6y ago

elitan 6y ago
Hi. We're excited to introduce you to Nhost! When building web and mobile apps, developers spend a considerable amount of time just to have a working skeleton deployed and ready-to-use. Things like provisioning and configuring servers, creating and configuring a database, implementing an API, authentication and authorization for users, storage for files and images, and a bunch of other security related work. Creating and maintaining all this infrastructure takes hundreds of hours and manual tasks each year. We believe that those things are better offloaded to domain experts so that you can focus on accelerating your product innovation and growth. Nhost allows products to get a ready-to-use, secure and performant backend in roughly 40 seconds, rather than months by integrating a bunch of open-source (no vendor lock-in) components and best practices. Let us know if you have any questions or suggestions, we would love to hear from you.
- nicoburns 6y ago
  This looks pretty great. Our SAAS product was initially based on Firebase, but we're in the process of migrating to almost the same stack that you are offering (but hosted on Heroku) as firebase is quite limiting Some feedback: - Have you considered offering compute? The ability to run a proper backend would be a dealbreaker for me. Not having a backend is advertised as simpler but in my experience it's the opposite, especially when integrating mobile apps that have a long lag time on updates. You simply don't get enough flexibility for complex tasks, even with something like Hasura. Heroku offers docker containers with fixed resources that might be a good way to go. If you could offer some kind of managed container service that allowed me to share resources between all my containers then even better. Maybe you could build something on / offer a managed version of https://github.com/dokku/dokku https://github.com/dokku/dokku ? - Managed Redis or some other in-memory caching service would also be super useful. This is really important for scaling efficiently. - Do you have any kind of availability / durability guarantees? This is super important for us at $DAYJOB as we provide similar guarantees to our clients. - Pricing seems reasonable, although a tier between Pro and Enterprise or a more "pay what you use" plan might be a good. We'd probably just about fit into the "Pro" tier for now but would be needing the Enterprise tier soon. We're currently paying more than the cost of the enterprise tier. However, that covers the cost of compute in addition to our databases and storage.
  - elitan 6y ago
    Interesting and thanks for the feedback! - Yes, either cloud functions (like Vercel's `/api` approach that we love) or docker containers (something like Google Cloud Run) will be one three big features we'll be working on next. - Noted! - Not right now. But as soon as we start getting those requests from customers we'll prioritise it. - Noted! Again, thanks for the feedback!
    - nicoburns 6y ago
      > Yes, either cloud functions (like Vercel's `/api` approach that we love) or docker containers (something like Google Cloud Run) will be one three big features we'll be working on next I'd love to use one of these serverless solutions (cloud run in particular looks great). But there is a key problem that they seem to share: cold starts. Our app doesn't see a lot of traffic, so we can happily run the entire thing on the equivalent of a small VM. If there was a massive traffic spike then I guess this would fall over, but we're an enterprise app so this is unliekly and we could fix that pretty quickly by provisioning more servers (in heroku this is as simple as dragging a slider). But even if we couldn't, falling over in abnormal conditions seems greatly preferable to there being a good chance of 3 seconds+ of latency being added to a normal everyday request. If you can solve this then you're on to a winner.
      - elitan 6y ago
        Interesting. Are cold starts such a good problem? Cold starts with Node (Javascript) seems to be around 200ms. But the best thing would probably be to have it as an option. Scale down to 0 (cold starts) or 1 (no cold starts).
        nicoburns 6y ago
        200ms would likely be fine (although not ideal), but I've seen more like to 3000ms with Firebase Cloud Functions, and have heard stories of similar with AWS Lambda. The fundamental problem seems to be the VM-or-container-per-request model. That means as soon as you get an extra concurrent user you have another cold start even if you already had one resource going. Whereas with a classic backend one server (even a small one) can handle thousands of concurrent requests and thus you have plenty of breathing room to start up another server before the current one gets completely bogged down.
chris_st 6y ago
I've been testing NHost the past few weeks, and I have to say that (A) it's fantastic, and (B) the support is even better. The combination of Postgres plus Hasura, plus a really nice smooth auth solution makes development and deploy fast and easy.
- elitan 6y ago
  This is why it's easy to wake up early every morning! Thanks!
ctrlaltdylan 6y ago
That's a dramatic jump in pricing from 0-5 GBs to > 5 GBs. Is there a more flexible pricing plan in the works? A hobbyist app could still be storing a large amount of data but not charging much to justify a $300/m db bill.
- elitan 6y ago
  Yea it's a constant trade off between offering a good service with a good and easy pricing. If you have custom needs I can help you out. Just send me an email: johan@nhost.io.
xrd 6y ago
This is so, so interesting. There have been lots of discussions about PouchDB and GunJs but they always seemed limited in the backend story. I've been trying to get Couchdb to work with my own proxies for about a year and it is a big pain point. But, the real time synchronization and offline support is so compelling with those stacks. Thinking in documents and only about your front end code (letting the library do the hard work of synchronization) removes a lot of stress. Using postgresql alone would make this super exciting. Adding graphql takes it to "giddy" level for me. Is there a story for offline support? Is there perhaps a react library that could help here? The tutorial uses subscriptions, wonder what happens when the app goes offline? This is so amazing. I'm going to play with it and Svelte and see how it goes. Well done!
- typingmonkey 6y ago
  You should try RxDB. It is based on pouchdb and therefore supports offline first [1]. Also you can use the graphql replication so that you are not limited to couchdb backend. Also there is a course made by hasura about using RxDB with their backend [2] disclaimer: I made RxDB [1] https://github.com/pubkey/rxdb https://github.com/pubkey/rxdb [2] https://hasura.io/learn/graphql/react-rxdb-offline-first/introduction/ https://hasura.io/learn/graphql/react-rxdb-offline-first/int...
  - juliushuijnk 6y ago
    Can it do 'offline first for couple of months'? Use case I'm thinking about: - At first the mobile app has no account, db is used without online backend. - Then user pays for premium features including online backup/sync. - This user then is created and all the data will be put in the online db and syncs, etc. - No local SQLite db or anything needs to sync, because you have this offline first database, that can handle offline only. This seems like an obvious use case to me, but have had trouble figuring out best path forward.
    - typingmonkey 6y ago
      Yes. It can even work fully without any server synchronization. It is just a db in the browser, sync is optional.
inian 6y ago
I have been bitten by Firebase scalability restrictions before, so good to see alternatives coming up. How do you compare to Supabase (http://supabase.io/ http://supabase.io/)?
- elitan 6y ago
  Thanks. Nhost and Supabase both use Postgres. The difference is that we use GraphQL (Hasura) for the API layer. We also offer authentication (email/password + OAuth) and storage (Minio S3) with permissions. I think I've read something about Supabase adding authentication recently or they are working on it (https://supabase.io/docs/library/authentication/ https://supabase.io/docs/library/authentication/).
  - kiwicopple 6y ago
    Thanks for the mention - I’m a cofounder of Supabase. Yes, we have released Auth, using Postgres Row Level Security and Netlify’s GoTrue. Here are the links you’re looking for: https://supabase.io/blog/2020/08/05/supabase-auth https://supabase.io/blog/2020/08/05/supabase-auth https://supabase.io/docs/library/user-management https://supabase.io/docs/library/user-management
Scarbutt 6y ago
If it is really a Firebase alternative, how does it manage live synchronization of data between users? or "cloud functions"? didn't find anything on the website.
- snorremd 6y ago
  https://docs.nhost.io/graphql/subscription https://docs.nhost.io/graphql/subscription Nhost seems to be based on the Hasura GraphQL server so you would implement live synchronization of data using GraphQL subscriptions. Hasura runs each subscription in a per second poll to get live data for each subscription. If the data changes it passes down the result to the graphql client. https://github.com/hasura/graphql-engine/blob/master/architecture/live-queries.md#scaling-to-1-million-active-graphql-subscriptions-live-queries https://github.com/hasura/graphql-engine/blob/master/archite...
  - zwily 6y ago
    It polls the database every second for every subscription? How does that scale to a lot of subscriptions?
    - elitan 6y ago
      You can read about it in detail here: https://hasura.io/blog/1-million-active-graphql-subscriptions/ https://hasura.io/blog/1-million-active-graphql-subscription...
  - Scarbutt 6y ago
    This is not the same at all as live synchronization between devices, also, the Firebase SDK clients allow for offline data persistence.
    - snorremd 6y ago
      Sorry I fail to see the big distinction between Firebase realtime synchronization and graphql subscriptions. There might be one, and I just don't see it as I'm not intimately familiar with Firebase. Firebase data retrieval definitions and graphql subscriptions look very similar too me. Both methods allow you to describe some data record(s) or document(s) to be fetched, fetches it, and then listens for server notifications about data changes for it including the changeset or new data. https://firebase.google.com/docs/database/admin/retrieve-data https://firebase.google.com/docs/database/admin/retrieve-dat... That clients receive events in milliseconds with Firebase and potentially with a second delay with Hasura is a performance detail. The functionality still serves the same general purpose? When one client modifies some document or record immediately notify all subscribing clients.
latchkey 6y ago
For some pricing perspective, I'm on firebase/cloud functions. I pay ~$10/month for their smallest cloud sql postgres instance and the rest of the usage pretty much falls under their free tier. For that $10, I get database backups, custom domains and no idea what team projects are, but I can add others to my project. On top of that, I also get everything else that firebase offers... task queue (PubSub), log analysis, hosting, realtime database, analytics, ability to hire someone who knows firebase/gcp, google's entire devops team. In order to get a bit closer to that level of features, I'd have to bump up to the $39/mo plan. While I appreciate the competition, this doesn't compete for me yet.
- brunoqc 6y ago
  > I'm on firebase/cloud functions. I pay ~$10/month for their smallest cloud sql postgres instance I don't know much about firebase. How does firebase relate to postgresql?
  - elitan 6y ago
    I was thinking about this too. I think the main reason you'd want to use Nhost instead of Firebase is for the tech we use. Mainly Postgres and GraphQL and how we got all services (database, api, auth, storage) working together very nicely, just like Firebase.
  - latchkey 6y ago
    Firebase is a whole suite of tools/services for building online apps. These apps can do things, like talk to a database. Cloud Firestore is a nosql database offering on Firebase. Cloud SQL Postgres is a database offering on GCP. Firebase Cloud Functions (FCF) are 'serverless functions'. You upload some code that looks like an Express app. I personally use the npm package 'apollo-server-cloud-functions' to provide Apollo Server GraphQL endpoints using 'type-graphql'. If you do it right, there is very little vendor lockin. I theoretically could use this same code on Nhost. Since it is all Google, Firebase can 'talk' to anything on GCP. Thus, my FCF can use 'mikro-orm' to talk to my cloud sql postgres database. I know, a lot of names... but once you wrap your head around it all, it starts to get a bit easier. The nice thing about all of this is that I get one small usage based bill every month and it just magically runs without any devops or thought on my part.
buzzerbetrayed 6y ago
I used Nhost a few months ago for a small project. The pricing was originally a huge block for me. I emailed them (elitan here on HN) to talk about pricing. He took my feedback and ended up giving me a big discount on a single project. Overall I was very impressed with the attention and customer service I got. I don't really use Nhost for anything currently, but I'm definitely rooting for them. The product is really well made, and is exactly what I was looking for at the time (a completely managed Hasura instance). For their sake, I wish they didn't have to compete with the insanely generous free tier of Firebase, as that's nearly impossible to compete with as a new company. I think the Nhost pricing model becomes much more reasonable as you scale in size. I hope to have the need to use Nhost again in the future. Would recommend.
wayneftw 6y ago
Are there any docs/issues/comments anywhere with information on how to self-host this?
- elitan 6y ago
  https://github.com/nhost/hasura-backend-plus https://github.com/nhost/hasura-backend-plus https://nhost.github.io/hasura-backend-plus/ https://nhost.github.io/hasura-backend-plus/
Rauchg 6y ago
Congrats on shipping! This looks amazing
- elitan 6y ago
  Thanks! What you’ve done with Vercel has been a great inspiration for us. We got lots of customers using Nhost for the backend, and Vercel for the frontend. Great combo!
mkarliner 6y ago
Have I missed something? How is this Open Source?
- elitan 6y ago
  Every Nhost project runs on open source software: - Database (PostgreSQL) - GraphQL API (Hasura) - Auth & Storage (Hasura Backend Plus) - Storage server (Minio) You can read more about self hosting here: https://github.com/nhost/hasura-backend-plus https://github.com/nhost/hasura-backend-plus We automatically configure and host these open source softwares as part of your Nhost project.
  - mike_d 6y ago
    When I decide to migrate off, will you give me all your custom glue to keep my website running?
    - technoplato 6y ago
      I am curious about this as well
    - elitan 6y ago
      100% yes. If you want to leave Nhost for some reason we'll help you with that. We already helped one customer in India doing this. They are a consultant agency and their customer had a requirement to be on AWS (We currently use Digital Ocean).
luminati 6y ago
How is auth implemented? Is keycloak or another oss package used or was it custom written?
- elitan 6y ago
  It's our own implementation. We support email/password and different OAuth providers (github, google, facebook etc) https://github.com/nhost/hasura-backend-plus https://github.com/nhost/hasura-backend-plus
anasbarg 6y ago
I've been working on a language for building GraphQL servers quickly. It use PostgreSQL for storage, it supports serverless functions using OpenWhisk, it allows you to write authorization rules, and it sets up user authentication workflows. The project is open-source, any feedback is highly appreciated: https://github.com/anasbarg/pragma https://github.com/anasbarg/pragma
gitgud 6y ago
One of the biggest advantages to firebase is its Blaze Plan, in which you pay for how much you use each service. This project seems to only have the standard 3 tier plan... Personally I prefer the pay as you go, as it's fair for both parties. Whereas with tiered payments, someone is always paying more than they need...
- elitan 6y ago
  Interesting. When we've talked to our customers they like the predictable pricing (like our 3 pricing tiers). But I agree with what you say. Having a "pay for what you use" is in a sense more fair, but less predictable.

210 points by elitan 6y ago

Hi. We're excited to introduce you to Nhost! When building web and mobile apps, developers spend a considerable amount of time just to have a working skeleton deployed and ready-to-use. Things like provisioning and configuring servers, creating and configuring a database, implementing an API, authentication and authorization for users, storage for files and images, and a bunch of other security related work. Creating and maintaining all this infrastructure takes hundreds of hours and manual tasks each year. We believe that those things are better offloaded to domain experts so that you can focus on accelerating your product innovation and growth. Nhost allows products to get a ready-to-use, secure and performant backend in roughly 40 seconds, rather than months by integrating a bunch of open-source (no vendor lock-in) components and best practices. Let us know if you have any questions or suggestions, we would love to hear from you.

nicoburns 6y ago
This looks pretty great. Our SAAS product was initially based on Firebase, but we're in the process of migrating to almost the same stack that you are offering (but hosted on Heroku) as firebase is quite limiting Some feedback: - Have you considered offering compute? The ability to run a proper backend would be a dealbreaker for me. Not having a backend is advertised as simpler but in my experience it's the opposite, especially when integrating mobile apps that have a long lag time on updates. You simply don't get enough flexibility for complex tasks, even with something like Hasura. Heroku offers docker containers with fixed resources that might be a good way to go. If you could offer some kind of managed container service that allowed me to share resources between all my containers then even better. Maybe you could build something on / offer a managed version of https://github.com/dokku/dokku https://github.com/dokku/dokku ? - Managed Redis or some other in-memory caching service would also be super useful. This is really important for scaling efficiently. - Do you have any kind of availability / durability guarantees? This is super important for us at $DAYJOB as we provide similar guarantees to our clients. - Pricing seems reasonable, although a tier between Pro and Enterprise or a more "pay what you use" plan might be a good. We'd probably just about fit into the "Pro" tier for now but would be needing the Enterprise tier soon. We're currently paying more than the cost of the enterprise tier. However, that covers the cost of compute in addition to our databases and storage.
- elitan 6y ago
  Interesting and thanks for the feedback! - Yes, either cloud functions (like Vercel's `/api` approach that we love) or docker containers (something like Google Cloud Run) will be one three big features we'll be working on next. - Noted! - Not right now. But as soon as we start getting those requests from customers we'll prioritise it. - Noted! Again, thanks for the feedback!
  - nicoburns 6y ago
    > Yes, either cloud functions (like Vercel's `/api` approach that we love) or docker containers (something like Google Cloud Run) will be one three big features we'll be working on next I'd love to use one of these serverless solutions (cloud run in particular looks great). But there is a key problem that they seem to share: cold starts. Our app doesn't see a lot of traffic, so we can happily run the entire thing on the equivalent of a small VM. If there was a massive traffic spike then I guess this would fall over, but we're an enterprise app so this is unliekly and we could fix that pretty quickly by provisioning more servers (in heroku this is as simple as dragging a slider). But even if we couldn't, falling over in abnormal conditions seems greatly preferable to there being a good chance of 3 seconds+ of latency being added to a normal everyday request. If you can solve this then you're on to a winner.
    - elitan 6y ago
      Interesting. Are cold starts such a good problem? Cold starts with Node (Javascript) seems to be around 200ms. But the best thing would probably be to have it as an option. Scale down to 0 (cold starts) or 1 (no cold starts).
      - nicoburns 6y ago
        200ms would likely be fine (although not ideal), but I've seen more like to 3000ms with Firebase Cloud Functions, and have heard stories of similar with AWS Lambda. The fundamental problem seems to be the VM-or-container-per-request model. That means as soon as you get an extra concurrent user you have another cold start even if you already had one resource going. Whereas with a classic backend one server (even a small one) can handle thousands of concurrent requests and thus you have plenty of breathing room to start up another server before the current one gets completely bogged down.

chris_st 6y ago

I've been testing NHost the past few weeks, and I have to say that (A) it's fantastic, and (B) the support is even better. The combination of Postgres plus Hasura, plus a really nice smooth auth solution makes development and deploy fast and easy.

elitan 6y ago
This is why it's easy to wake up early every morning! Thanks!

ctrlaltdylan 6y ago

That's a dramatic jump in pricing from 0-5 GBs to > 5 GBs. Is there a more flexible pricing plan in the works? A hobbyist app could still be storing a large amount of data but not charging much to justify a $300/m db bill.

elitan 6y ago
Yea it's a constant trade off between offering a good service with a good and easy pricing. If you have custom needs I can help you out. Just send me an email: johan@nhost.io.

xrd 6y ago

This is so, so interesting. There have been lots of discussions about PouchDB and GunJs but they always seemed limited in the backend story. I've been trying to get Couchdb to work with my own proxies for about a year and it is a big pain point. But, the real time synchronization and offline support is so compelling with those stacks. Thinking in documents and only about your front end code (letting the library do the hard work of synchronization) removes a lot of stress. Using postgresql alone would make this super exciting. Adding graphql takes it to "giddy" level for me. Is there a story for offline support? Is there perhaps a react library that could help here? The tutorial uses subscriptions, wonder what happens when the app goes offline? This is so amazing. I'm going to play with it and Svelte and see how it goes. Well done!

typingmonkey 6y ago
You should try RxDB. It is based on pouchdb and therefore supports offline first [1]. Also you can use the graphql replication so that you are not limited to couchdb backend. Also there is a course made by hasura about using RxDB with their backend [2] disclaimer: I made RxDB [1] https://github.com/pubkey/rxdb https://github.com/pubkey/rxdb [2] https://hasura.io/learn/graphql/react-rxdb-offline-first/introduction/ https://hasura.io/learn/graphql/react-rxdb-offline-first/int...
- juliushuijnk 6y ago
  Can it do 'offline first for couple of months'? Use case I'm thinking about: - At first the mobile app has no account, db is used without online backend. - Then user pays for premium features including online backup/sync. - This user then is created and all the data will be put in the online db and syncs, etc. - No local SQLite db or anything needs to sync, because you have this offline first database, that can handle offline only. This seems like an obvious use case to me, but have had trouble figuring out best path forward.
  - typingmonkey 6y ago
    Yes. It can even work fully without any server synchronization. It is just a db in the browser, sync is optional.

inian 6y ago

I have been bitten by Firebase scalability restrictions before, so good to see alternatives coming up. How do you compare to Supabase (http://supabase.io/ http://supabase.io/)?

elitan 6y ago
Thanks. Nhost and Supabase both use Postgres. The difference is that we use GraphQL (Hasura) for the API layer. We also offer authentication (email/password + OAuth) and storage (Minio S3) with permissions. I think I've read something about Supabase adding authentication recently or they are working on it (https://supabase.io/docs/library/authentication/ https://supabase.io/docs/library/authentication/).
- kiwicopple 6y ago
  Thanks for the mention - I’m a cofounder of Supabase. Yes, we have released Auth, using Postgres Row Level Security and Netlify’s GoTrue. Here are the links you’re looking for: https://supabase.io/blog/2020/08/05/supabase-auth https://supabase.io/blog/2020/08/05/supabase-auth https://supabase.io/docs/library/user-management https://supabase.io/docs/library/user-management

Scarbutt 6y ago

If it is really a Firebase alternative, how does it manage live synchronization of data between users? or "cloud functions"? didn't find anything on the website.

snorremd 6y ago
https://docs.nhost.io/graphql/subscription https://docs.nhost.io/graphql/subscription Nhost seems to be based on the Hasura GraphQL server so you would implement live synchronization of data using GraphQL subscriptions. Hasura runs each subscription in a per second poll to get live data for each subscription. If the data changes it passes down the result to the graphql client. https://github.com/hasura/graphql-engine/blob/master/architecture/live-queries.md#scaling-to-1-million-active-graphql-subscriptions-live-queries https://github.com/hasura/graphql-engine/blob/master/archite...
- zwily 6y ago
  It polls the database every second for every subscription? How does that scale to a lot of subscriptions?
  - elitan 6y ago
    You can read about it in detail here: https://hasura.io/blog/1-million-active-graphql-subscriptions/ https://hasura.io/blog/1-million-active-graphql-subscription...
- Scarbutt 6y ago
  This is not the same at all as live synchronization between devices, also, the Firebase SDK clients allow for offline data persistence.
  - snorremd 6y ago
    Sorry I fail to see the big distinction between Firebase realtime synchronization and graphql subscriptions. There might be one, and I just don't see it as I'm not intimately familiar with Firebase. Firebase data retrieval definitions and graphql subscriptions look very similar too me. Both methods allow you to describe some data record(s) or document(s) to be fetched, fetches it, and then listens for server notifications about data changes for it including the changeset or new data. https://firebase.google.com/docs/database/admin/retrieve-data https://firebase.google.com/docs/database/admin/retrieve-dat... That clients receive events in milliseconds with Firebase and potentially with a second delay with Hasura is a performance detail. The functionality still serves the same general purpose? When one client modifies some document or record immediately notify all subscribing clients.

latchkey 6y ago

For some pricing perspective, I'm on firebase/cloud functions. I pay ~$10/month for their smallest cloud sql postgres instance and the rest of the usage pretty much falls under their free tier. For that $10, I get database backups, custom domains and no idea what team projects are, but I can add others to my project. On top of that, I also get everything else that firebase offers... task queue (PubSub), log analysis, hosting, realtime database, analytics, ability to hire someone who knows firebase/gcp, google's entire devops team. In order to get a bit closer to that level of features, I'd have to bump up to the $39/mo plan. While I appreciate the competition, this doesn't compete for me yet.

brunoqc 6y ago
> I'm on firebase/cloud functions. I pay ~$10/month for their smallest cloud sql postgres instance I don't know much about firebase. How does firebase relate to postgresql?
- elitan 6y ago
  I was thinking about this too. I think the main reason you'd want to use Nhost instead of Firebase is for the tech we use. Mainly Postgres and GraphQL and how we got all services (database, api, auth, storage) working together very nicely, just like Firebase.
- latchkey 6y ago
  Firebase is a whole suite of tools/services for building online apps. These apps can do things, like talk to a database. Cloud Firestore is a nosql database offering on Firebase. Cloud SQL Postgres is a database offering on GCP. Firebase Cloud Functions (FCF) are 'serverless functions'. You upload some code that looks like an Express app. I personally use the npm package 'apollo-server-cloud-functions' to provide Apollo Server GraphQL endpoints using 'type-graphql'. If you do it right, there is very little vendor lockin. I theoretically could use this same code on Nhost. Since it is all Google, Firebase can 'talk' to anything on GCP. Thus, my FCF can use 'mikro-orm' to talk to my cloud sql postgres database. I know, a lot of names... but once you wrap your head around it all, it starts to get a bit easier. The nice thing about all of this is that I get one small usage based bill every month and it just magically runs without any devops or thought on my part.

buzzerbetrayed 6y ago

I used Nhost a few months ago for a small project. The pricing was originally a huge block for me. I emailed them (elitan here on HN) to talk about pricing. He took my feedback and ended up giving me a big discount on a single project. Overall I was very impressed with the attention and customer service I got. I don't really use Nhost for anything currently, but I'm definitely rooting for them. The product is really well made, and is exactly what I was looking for at the time (a completely managed Hasura instance). For their sake, I wish they didn't have to compete with the insanely generous free tier of Firebase, as that's nearly impossible to compete with as a new company. I think the Nhost pricing model becomes much more reasonable as you scale in size. I hope to have the need to use Nhost again in the future. Would recommend.

wayneftw 6y ago

Are there any docs/issues/comments anywhere with information on how to self-host this?

elitan 6y ago
https://github.com/nhost/hasura-backend-plus https://github.com/nhost/hasura-backend-plus https://nhost.github.io/hasura-backend-plus/ https://nhost.github.io/hasura-backend-plus/

Rauchg 6y ago

Congrats on shipping! This looks amazing

elitan 6y ago
Thanks! What you’ve done with Vercel has been a great inspiration for us. We got lots of customers using Nhost for the backend, and Vercel for the frontend. Great combo!

mkarliner 6y ago

Have I missed something? How is this Open Source?

elitan 6y ago
Every Nhost project runs on open source software: - Database (PostgreSQL) - GraphQL API (Hasura) - Auth & Storage (Hasura Backend Plus) - Storage server (Minio) You can read more about self hosting here: https://github.com/nhost/hasura-backend-plus https://github.com/nhost/hasura-backend-plus We automatically configure and host these open source softwares as part of your Nhost project.
- mike_d 6y ago
  When I decide to migrate off, will you give me all your custom glue to keep my website running?
  - technoplato 6y ago
    I am curious about this as well
  - elitan 6y ago
    100% yes. If you want to leave Nhost for some reason we'll help you with that. We already helped one customer in India doing this. They are a consultant agency and their customer had a requirement to be on AWS (We currently use Digital Ocean).

luminati 6y ago

How is auth implemented? Is keycloak or another oss package used or was it custom written?

elitan 6y ago
It's our own implementation. We support email/password and different OAuth providers (github, google, facebook etc) https://github.com/nhost/hasura-backend-plus https://github.com/nhost/hasura-backend-plus

anasbarg 6y ago

I've been working on a language for building GraphQL servers quickly. It use PostgreSQL for storage, it supports serverless functions using OpenWhisk, it allows you to write authorization rules, and it sets up user authentication workflows. The project is open-source, any feedback is highly appreciated: https://github.com/anasbarg/pragma https://github.com/anasbarg/pragma

gitgud 6y ago

One of the biggest advantages to firebase is its Blaze Plan, in which you pay for how much you use each service. This project seems to only have the standard 3 tier plan... Personally I prefer the pay as you go, as it's fair for both parties. Whereas with tiered payments, someone is always paying more than they need...

elitan 6y ago
Interesting. When we've talked to our customers they like the predictable pricing (like our 3 pricing tiers). But I agree with what you say. Having a "pay for what you use" is in a sense more fair, but less predictable.