Sure! We want to build something flexible where users can define their own custom objects and fields. We were thinking about leveraging Hasura that's already providing a flexible graphql API based on metadata which is exactly what we need / will need to build in the future.

However, there are three reasons that pushed us to go through a different way:

1) We want to build a cloud version which is multitenant (I personally think that provisionning single tenant instance at scale is not a good vision in a world with restricted resources ; there is a significant resource saving when we mutualize resources). This means that different users can have different data schemas. This is not possible with Hasura that serves one unique schema for all users.

2) We want to offer a good developer experience and Hasura comes as a standalone service. This means that installing the project gets much more complex than a "yarn && yarn start", and creates a harder onboarding curve which we want to avoid as much as possible. If you face a Hasura issue during installation, you would need to understand Hasura workflows, and probably docker too.

3) Very similar to 2, we want Twenty to be easily self-hostable with 1-click to deploy. This would had pushed us to create bigger joint images including Twenty + Hasura, making it harder to maintain and to debug.

There is a great article on how Salesforce is built here: https://architect.salesforce.com/fundamentals/platform-multi.... They basically have 1 metadata table and 1 data table (uuid, objectid, orgid, field1, ..., field500) where each column is a VARCHAR and they have built their own engine on top of it. I think we will likely need to do something similar and we cannot build it on top of Hasura / we lose the value of Hasura by building on top of it.

Ah, yep that makes complete sense if you want to per-tenant schemas. My app is multi-tenant but all have the same schema. We use a customer_id column that's matched against the JWT's customer_id token to ensure that no data is shared inadvertently by a dev missing adding a WHERE clause.

Thanks for the SF link, that's quite interesting. It seems bonkers to me to throw away all the advantages of the RDMS but you can't argue with their success.

A middle ground I've encountered in an ERP system (prophet21 if you're interested) was each table had multiple "CUSTOM_XX" columns that were initially blank. Customers could edit their UI and would drag/drop the custom columns onto the appropriate form and change the label to be whatever they'd like. That gave them some flexibility but kept the core schema coherent.

A middle ground I've encountered in an ERP system (prophet21 if you're interested) was each table had multiple "CUSTOM_XX" columns that were initially blank. Customers could edit their UI and would drag/drop the custom columns onto the appropriate form and change the label to be whatever they'd like. That gave them some flexibility but kept the core schema coherent.

> Interesting, I will look into that, thank you!

Regarding the different schemas / metadata, I would've thought that Hasura would still be super useful for everything else. So a custom API for metadata and Hasura for everything else. That said, I've never used Hasura so I can't exactly tell.

The multitenant sharing of one large table with uuid seems rather crazy.

I'm rather worried about having a large table being able to accommodate for any custom object than the fact it is multi-tenant, we could shard by tenant_id quite easily.

I might be missing your point and I'm far from being a database expert. Would you give me more details about what challenge you have in mind?

An index on all 500 fields!