Can I use script automation lookup values from a separte Airtable base?

[Richard_Foxwort]

I’m hitting my 50,000 record limit and need to reduce size of my main base pending a more serious migration to a more scalable platform altogether.

An obvious candidate for me is to eliminate my Postcode lookup table - this table contains many thousands of records and its useful for auto-populating my Users table with relevant locality data by inputting only the postcode.

Is there any restriction on moving the postcode lookup table to an entirely new and separate base, then using a script automation to perform equivalent lookup functionality via API?

ie can I use an Airtable script automation to hit the Airtable API and retrieve data from a remote Airtable base?

[Alexey_Gusev]

Hi,

Maybe i don’t understand correctly a structure of your table, but
why don’t you use a kind of partitioning in the same base?
Like split Postcode table into 10 tables x 5k records (based on the first digit or whatever)

i had some task that required a kind of 2-side record connection between several bases, checked possible options including API usage, evaluated the amount of headache building the solution, and choose other way, without splitting to bases,

[Richard_Foxwort]

Its because I need to make some room in my main base which is now at the 50,000 record limit.

If I can migrate my postcode table to a different base, then I have some breathing room.

[Alexey_Gusev]

i thought it’s the “per table” limit, not “per base”

[kuovonne]

The record limit is per base, not per table. However there may also be undocumented limits on the number of records per table.

It is possible to use the Airtable REST API to connect to a different base, but it should only be done with extreme caution and full understanding of the risks involved. For one thing, the script would expose your API key to everyone with access to the base, which is a huge security risk.

What about another scripting alternative? Your postcode data probably doesn’t change very often. Instead of storing it in a table with thousands of records, try storing the data in JSON format in a long text field. Depending on the amount of data, you may be able to consolidate the data into one or possibly a handful of records. Then have the script read the postcode JSON data from the reference table and insert the proper information into an editable field in your actual records. You may need a script to update existing records, and then a different automation script to manage ongoing records.

You could also use a script to convert the current information in table format into JSON format. If the data tends to change, you could keep a separate base with your postcode information, and have a script write the data to JSON format in a different table in that same base. Then sync that smaller table of JSON data into your current base. This way you could manage the postcode data in table format, and still reduce the record count in your main base.