I think what’s being missed here is that Coda is a growing product and all of this doesn’t happen at once. When you say…
I am 100% convinced that the things I am building in Coda right now would not have happend in any other environment I have tried to this date.
That’s because of the focus on features and how the product functions. We can strip a lot of that away and only focus on performance, then you’re stuck saying that you need more features. In reality, both sides are seeing improvements and both features and performance will continue to get better.
The question is do you want a data repository or do you want a doc that functions like an app? If you want hundreds of thousands to millions of data points, you’re looking at a data repository. If you’re looking at thousands to tens of thousands, then a doc can work. Getting to the upper end of that will require efficient doc building and time for the product to get there. I also have a Coda doc that has ~10,000 rows and it loads in at 18 MB, so I still have a lot of room to grow here. It depends on your mix of features and data and engineering the doc to work for what you need. I’ve also crashed Google Sheets at 100,000 rows, so Coda really isn’t far off in capacity.
For sharing, I think you’re looking at a data repository with a frontend interface that has a lot of control over what is displayed and how it’s accessed. Coda is not an app builder, it’s a doc that is easy to jump into and create an app-like experience. If you need to keep some data more secure than other data, you can use Cross-doc to pull in only the relevant data and keep the other doc private.
It sounds like you’re describing use-cases of running databases and reaching for those types of functions. Coda might not be right for this particular use-case. All I can say is that it will continue to grow in both function and performance.