Skip to main content
Question

How to design base structure for over 50k or 125k record amounts?

  • March 8, 2026
  • 2 replies
  • 22 views
0
Forum|alt.badge.img+17

Hi,

We’re looking at adding new data with potentially a lot of records to our base, so I’m wondering how to design that.

The overall question is then if one can spread out distinct data types to other bases, and thereby be able to significantly increase the records quota?

We’re currently at the Team plan with 50k records allowed and already using 19k of the quota. I have not seen a way to buy just more records quota. We don’t really need the additional Business plan features right now, and also that is still capped at 125k records.

The data we’ll adding for our CRM/ERP is bank transactions and invoice data. Both of these have before been handled in external systems, thereby creating manual work and complex maintenance.

Bank transactions could be10-30 per day now, but could increase manyfold within some years. Already 50 per day would mean 18k records per year.

Invoice data would probably need an invoice header table and line items table, where each product would need its own record for audit trail purposes (I guess we can’t use linked records because if we link to the products data will change if we change the products’ prices or VAT rates). 200 invoices per month with 5 products would then make over 12.000 records a year.

What is the proper and robust approach to design this? One base for Bank Data and another for Invoice Data? How to set that up then? What to do when they reach 50k records?

Rgds,

Björn

2 replies

Reagan
Forum|alt.badge.img+1
  • Reagan
  • New Participant
  • March 8, 2026

Hi!

I can spitball with you here because I have seen others have the same issues.

First idea:

  • Since the record limit is per base, I would say that you could capture what you need and when you reach your limit:
    • make a copy of the base → rename the copy and make sure people know that it is historical → clear out your core/working base of all data.

This option would require a bit of management/manual work for you guys but I have seen it work. Many would initiate the change at a timeframe so essentially  they would have a base per quarter/month/whatever makes sense.

Second idea:

  • You could use Airtable’s API capabilities to connect to a database to store historical data. I think you can even set it up to work with Excel as well, but excel is not a database so you will have limits there as well.
    • You may also be able to integrate your 

I am not an expert in this area so I may be completely wrong about this.

Third idea:

  • Export your base into excel or csv and follow the same protocol as the first idea.

Final Note:

Your record limit is per base, not per workspace. So you can have 20 bases that are capped in your workspace! Archiving shouldn’t be an issue and is probably going to be your best bet.

 

I also found a couple of posts with similar issues:

I am not an expert so please let me know if these aren’t great ideas. Would love to hear other’s ideas!

 

TheTimeSavingCo
Forum|alt.badge.img+31

If the issue we’re trying to solve is purely record limits then I’d say just duplicate the base to keep as an archive, then clear out the data on the main base as it’s the easiest, fastest solution.  The main thing we need to watch out for are any automations that would react badly to the data going missing, and so I’d recommend building a system / automation that helped you clear out the data without tripping things up

 

If you were generating a massive amount of data then an argument could be made to build a system that’ll help you auto-archive the data so that you’re not duplicating the base every week or something, but at the numbers you’re talking about it seems like you’d be able to do the duplication yearly, which seems fine?
 

This becomes slightly trickier if you need long term reporting, and in those situations we’d end up:

  1. Creating a reporting base
  2. In each of the archive bases, create a summary table (e.g. summarize by month maybe)
  3. Sync the summary tables to the reporting base

---
If possible, I’d advise against creating a dedicated ‘Invoices’ or ‘Bank Data’ bases that sync back to the main base because of the limitations that come around synced tables.  Automations have serious limitations currently for synced tables, and revision history also becomes kind of tricky to track, so you’d need to build your own revision history tracking system if that mattered to you.  Still, if needs must...

Adam, Airtable Consultant - thetimesaving.company
Terms & ConditionsAccessibility statement