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.
And then, your projects start to scale hand your bill goes up exponentially. Firebase start to become 70% of your total business cost. You look for alternatives but soon realise that it would be an immense effort to move away since you have everything interconnected in Firebase. So you take it. Until one day, something changes: a policy, a feature, maybe your gmail account gets banned and your firebase closed. And you still have all the eggs in the same basket and can't move them.
Now I wrote this as an answer to you, but it's in reality just speculation and the reason why I avoid Google (and Amazon) services like the plague. They are competitive but just the possibility of the above scenario happening would keep me up at night.
This isn't necessarily true. I helped build a business on top of AppEngine. We did $80m gross in our first year. Our bill went up to about $500 a month. Why so low? Because we designed the system to scale from the start. We became experts in how to make the system work for us. We knew what would end up costing us money, so we engineered it from the start so it wouldn't cost us money.
Here is the case study written after I left the company...
I looked at what you're doing. I don't want to learn to write GraphQL markup in a new DSL. Honestly, what you've created is a solution looking for a problem.
Do you prefer a UI? Like Hasura, AppSync, 8base, and firebase? The DSL is very very close to GraphQL’s SDL though, so learning it shouldn’t take more than 5 minutes.
The problem we’re solving is the tediousness of building a GraphQL API.
We decided to work on this 14 months ago because me and my co-founder have built many backend systems and 99% of the time it’s just CRUD, auth and some validation and transformation logic, yet it would still take a lot of time to get something done.
The problem is very clear to us, but we’re trying to refine the solution to have something that is 10x better than what is already in the market.
We went with the DSL route because we wanted to support as many languages as possible for “turing complete” logic and not get tied up to one language. Also, text is great, and running locally is even better because it gives you the freedom to integrate it into any system very easily, unlike UI-based cloud solutions which are neither text nor run locally.
The GraphQL API isn't tedious. I write one language, TypeScript. The rest is all automatically generated for me. Fully typesafe, easy to unit test, fast to add features, not much boilerplate. Check out: type-graphql + https://graphql-code-generator.com/
Yeah GraphQL APIs are not tedious to work with, I LOVE GraphQL Codegen for TypeScript and it works very well with my DSL. What's tedious is building a GraphQL API, not consuming it.
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.
I have an iOS Flutter and a webapp that talks to this as a backend for my business. It is private and all low usage, but I like the idea that this is infinitely scalable and doesn't require any effort to maintain.
Infinitely scalable's a bit of myth in my experience. We've switched firebase app to a small postgres instance and have seen all of our performance issues magically melt away.
Cloud Firestore how does that relate to Datastore? Really wish Google would allow multi-region Cloud SQL like AWS allows with RDS. Datastore is such a pain to use with its index requirements
Cloud Firestore scales just fine, like any database, you have to know how to work with it. You switched from a nosql database to a sql database... two totally different performance profiles.
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.
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.