This message was deleted.
# questions
b
This message was deleted.
e
@dry-byte-39442 It depends on how you’re syncing tables and rows. If you’re making them read-only by always syncing, then the app using Base B would be less useful because we couldn’t write to it. If you’re occasionally copying content over, then Base B would be more efficient. That said, could you clarify what you mean when you say very large? In general, a big base is not a problem if the load is spread into a lot of tables. If a particular table has 80 k + rows, I would imagine it making a performance hit.
r
From experience I would say that it’s not just about row count. We have tables that are 10k or 20k in rows but have 400+ fields, including many rollups and lookups. These are very slow as well. In talking to Airtable, they view us as one of their 20 or so most “load heavy” customers, at least they did 6 months ago or so.
d
Hi @elegant-eve-85294 and @rich-thailand-76551 Base A has 25 tables, 2k columns and 300k rows. It's been cleaned-up recently so it does not contain totally unnecessary columns, although it contains a lot of formulas, lookups and rollups.
🙇 1
r
That’s an average of 80 columns per table. Which is not bad, but are their key tables that have a lot more?
d
Yes. There are roughly 5 tables having each ~200 columns and the rest is spread over the remaining 20 tables.
r
L that’s likely not a problem. Do you ever find yourself waiting for AirTable to “catch up” when you edit or delete something? Or add a new column?