Are you using our SaaS platform (Baserow.io) or self-hosting Baserow?
SaaS
What are the exact steps to reproduce this issue?
I have a table (Jobs) the has 48 columns (41 editable columns, 7 lookup of link to table columns).
Currently when I make a change to Jobs Table a webhooks is generated, I subsequently make 2 API patch calls to update the Jobs table.
I could move 8 of the editable columns to a separate table (References)
however this would mean I will have to make an 2 additional API calls (1 get and 1 patch) to get and update the references each time I make a change to the Jobs table .
I’m aware Baserow does not like tables with lots of columns, so I’m wondering which of the above is preferable?
It’s hard to give a general answer for a specific case. Generally, the more columns a table has, the slower it becomes. However, splitting columns into another table while preserving relationships typically doesn’t improve performance—in fact, it might even worsen it. Fewer columns and relationships should speed things up, but I understand that relationships are often necessary.
To get a better idea, we’d need to measure the performance. One idea we’re considering is moving all relationship and formula updates into a separate task since that part takes the most time, but the implications are complex, so it’s too early to say if or when that will be available.
To see if we can do anything else, I’d need:
An export of your database schema so we can replicate your setup locally.
Details on how your webhooks are registered and what they do.
Information on which operations are slow and how slow they are (with some numbers)
the requests and the payload you use to get and update the row. If the get part is slow, maybe we can easily make it faster searching for an indexed field
I can’t promise a quick solution, but I’ll investigate. The simpler it is for us to replicate the issue, the better our chances of resolving it promptly.