Hi, Nuno from Nhost here.
A bit of context: Hasura v2 has been the core of Nhost’s GraphQL layer for years. We built Constellation because we wanted to keep this part of our stack open source and have more control over the GraphQL/permissions layer.
It is still early. Today it runs alongside Hasura, and Hasura still owns metadata authoring. The part we are focusing on first is compatibility on the GraphQL request path: metadata -> schema per role -> `/v1/graphql`.
The most useful feedback for us would be from people with real Hasura projects: schema diffs, metadata that does not work, behavioral differences, or queries that produce different results.
Happy to answer technical questions about the implementation, compatibility layer, or why we chose Go.
Better to migrate to something open-source without vendor lock-in while small. If you need any help to understand what would be needed, feel free to email me at [email protected].
The mobile push service is indeed a great feature from Firebase, which we will also implement when possible. We already provide a realtime API through GraphQL subscriptions.
I hope to have a more detailed analysis to share when we have more accurate data. We launched individual instances recently and although I don't have exact numbers, the price difference will be significant. Just imagine how much it would cost to have 1 RDS instance per tenant (we have thousands).
We haven't open-sourced any of this work yet but we hope to do it soon. Join us on discord if you want to follow along (https://nhost.io/discord).
Sorry for not answering everyone individually, but I see some confusion duo to the lack of context about what we do as a company.
First things first, Nhost falls into the category of backend-as-a-service. We provision and operate infrastructure at scale, and we also provide and run the necessary services for features such as user authentication and file storage, for users creating applications and businesses. A project/backend is comprised of a Postgres Database and the aforementioned services, none of it is shared. You get your own GraphQL engine, your own auth service, etc. We also provide the means to interface with the backend through our official SDKs.
Some points I see mentioned below that are worth exploring:
- One RDS instance per tenant is prohibited from a cost perspective, obviously. RDS is expensive and we have a very generous free tier.
- We run the infrastructure for thousands of projects/backends which we have absolutely no control over what they are used for. Users might be building a simple job board, or the next Facebook (please don't). This means we have no idea what the workloads and access patterns will look like.
- RDS is mature and a great product, AWS is a billion dolar company, etc - that is all true. But is it also true that we do not control if a user's project is missing an index and the fact that RDS does not provide any means to limit CPU/memory usage per database/tenant.
- We had a couple of discussions with folks at AWS and for the reasons already mentioned, there was no obvious solution to our problem. Let me reiterate this, the folks that own the service didn't have a solution to our problem given our constraints.
- Yes, this is a DIY scenario, but this is part of our core business.
I hope this clarifies some of the doubts. And I expect to have a more detailed and technical blog post about our experience soon.
By the way, we are hiring. If you think what we're doing is interesting and you have experience operating Postgres at scale, please write me an email at [email protected]. And don't forget to star us at https://github.com/nhost/nhost.
It is still early. Today it runs alongside Hasura, and Hasura still owns metadata authoring. The part we are focusing on first is compatibility on the GraphQL request path: metadata -> schema per role -> `/v1/graphql`.
The most useful feedback for us would be from people with real Hasura projects: schema diffs, metadata that does not work, behavioral differences, or queries that produce different results.
Happy to answer technical questions about the implementation, compatibility layer, or why we chose Go.