Table Editor Performance issues

Hey there,

I’ve developed several apps using AppSmith which comprise of around 8 pages, each with an infinite scrolling table that contain up to 120 columns. Each cell in the table triggers an update query to my Postgres database whenever the cell is updated, to imitate the behavior of Excel/Google Sheets.

I have a few questions regarding performance which I’ve already faced:

1 - How many rows can these tables realistically display at once? I’m experiencing major lag when a cell updates.

2 - The widget editor itself is being super laggy and glitchy. Whenever I want to change the name of a column for example, the AppSmith UI takes about 5-10 seconds to respond to my initial click to begin editing, when I’m typing, there’s a good 5 second delay too. It also takes a while to be able to enter the editor for a given column aswell. Is there anything that I can do to rectify this issue or does this just come with having 100+ columns? The same issue occurs on my smaller tables of ~20 rows.

3 - Will AppSmith be able to support having ~10 users per app editing several rows at once?

Thanks in advance, AppSmith is a great resource for those getting started!

Hello Benjamin, and welcome to our community!

If you need to display large data sets in your table, we recommend implementing server-side pagination to avoid performance issues. Appsmith supports responses up to 5 MB at a time. Here are some of our guides that should help:

Would this approach work for your use case?

As for the performance issues you are facing in the editor, could you please help us with the following information?

  1. Are you on cloud or self-hosted? What is your Appsmith version?

  2. What is your network speed and system specs?

  3. Could you share a screen recording showing the slowness you are facing?

  4. Share the performance profiles by following the steps from this guide -

Thanks for the warm welcome!

Unfortuantely with the use case that we have, we’ll need something with infinite scrolling support. We’re looking to replicate Google Sheets’ functionality so this is a must!

I calculated how many rows of our largest Postgres table (column wise) are in 5MB and it’s equal to 1901 rows. We had ~20 rows on display and we were already facing issues.

As for the editor questions:
1 - Cloud, v1.9.9
2 - 92.5 Mbps download, 3.9 Mbps upload. I’m using a MacBook M1 Air running MacOS Monterey 12.3.1 with 8GB of memory.
3 -
4 - Google Drive of profiles



Edit: Formatting

@benjaminbialy in this case, the issue could be that you are using 120 columns. This doesn’t seem like a viable way for your users to work with the table. Have you considered only returning the columns that can be visible on the screen?
So instead of a select * statement, would it be viable to only select the columns your users need to see at a given point in time?

Hi Nikhil,

We have several smaller tables with < 20 columns for which the same issues are arising.

Is there a specific amount of columns that will hold up fine from your understanding?


@benjaminbialy how many rows do those have? Typically we see that around 40k cells i.e 20 columns x 2000 rows should be fine. We’re working on improving the virtualization for columns as well here to help this.

@Nikhil <20 rows on the smaller tables. It’s a lot more usable than the larger tables but still hard to work with.

I have several select dropdowns in table which could be an issue? The queries to fetch the options only run once on the first page load though.

It’s very odd.

That should not be the case unless the smaller tables are also on the same page as the large tables in which case, it’s those that are slowing the entire app down. Could you invite to your ap? We’ll have a look at what is going wrong

Hi @benjaminbialy ,
— Sorry. I thought I posted this yesterday, it was still in my drafts.

  • What is the size of data your loading. Number of columns and rows in your API/Query response.
  • How much of the above data are you displaying in table.

Sure thing, invite sent. The main culprit is the “Places” App. Every table is on a separate page, that shouldn’t be an issue should it?

No worries Satish!

We are loading nowhere near 5MB of data, I should be able to display 1900 rows (with 120 columns) before running into that size of data.

At the moment I’m displaying all of my data in the table, attempting to replicate Google Sheets’ UI/UX, in the largest table there’s about 100 columns with 30 odd rows.

On the smaller ones, 12-20 columns with about 20 rows, if that.

I have several apps all containing about 7 tables each. The issue is much worse on the larger columned tables but still present on the smaller ones too.

To your understanding, do columns have a greater impact on performance compared to additional rows? I get the sense that it’s more to do with the number of columns than it does with the rows.


Upto 5MB of data is fine when you are using pagination.
In the places combined page you are rendering 160 rows with 90 columns, I believe thats the reason for slowdown you are experiencing.

Normally this would be handled by virtualization, but virtualization doesn’t work with dynamic row height.

Can you please try by setting this as table data {{,10}} and let us know if it makes things better for you.

When virtualization is in play, usually rows are virtualized so number of rows don’t have any significant performance impact.

That worked well! Appsmith’s performance has improved from when I opened this forum.

Do you guys have any plans to support row virtualisation on dynamic row heights?

I assume dynamic row heights are caused by my text inputs with cell wrapping, if I get rid of them how many rows can I expect to be able to display?

Last question :laughing:, does Appsmith plan to support infinite scrolling?


@benjaminbialy regarding dynamic row height virtualisation, we haven’t been able to crack it yet. We are yet to figure out if it will work well or not, if you plan to use wrapping i suggest not to exceed 50 records on a page to be very safe.

Coming to infinite scrolling we do plan to support, but we are looking for people who can help us understand why their use-case needs infinite scrolling. Can you help us out with some details on your app, your users and why you need infinite scrolling in the table?

If you would like to have this conversation on a call instead, it would help me prioritise this better. Here’s a link to my calendar if you are willing to talk to us - Calendly - Dilip Pitchika