How are you structuring Airtable for media operations at scale?

As someone who is just starting to build out their operational systems for live events on AirTable, I am definitely interested in this conversation! I am quickly forecasting the exact situation you spelled out here where we are hitting record limits and breaking down the associated workflows. We aren’t large scale, but we are supporting 50-80 events per year and the details are quickly stacking up (we haven’t even touched our education or graphic groups’ needs).

We’re working through these same exact questions in higher ed for our degree program catalogs. While we haven’t found permanent fixes, this is we’ve implemented so far that seems to be working for us:

• Yes, our data is separated across multiple synced bases, which was prompted by us hitting the limit on automations. We’re in the process of moving towards a more “unit-focused” Airtable system where a base is dedicated to a single portfolio item—e.g. degree programs, space and capital projects, institutional data—rather than forcing a single base to maintain all three.
• We’re moving towards a “template model” where our tables are fixed, but records are not. This allows us to archive records—exporting the entire table as .csv file, which unfortunately wipes any attachments and images—at the end of an academic year, wipe the table except for the most recent record for a given degree program, and then continue using the base. Our records are all linked in a versioned auditing system so we’re able to trace the most current record back to its archived versions in the .csv files.

Hey @sandra_k_o , ​@Blessing_Nuga – this resonates. I had to tackle record limitations and general base sprawl both managing the DET (Disney Entertainment Television) Airtable ecosystem and most recently a big NPR station.

In both occurrences there are various approaches depending on the use of the data. My three main approaches were (in order of complexity):

1. Summary fields (basically extracting just the data needed for reporting out of archived records)
2. Archiving and de-archiving automations (via Syncs or (storing records as JSONs in Long Text fields)
3. HyperDB

These approaches were utilized depending on how the ‘overage’ data was supposed to be used, whether it was only needed for reporting purposes (i.e. you wanna know how many hours your team worked last year on an episode basis, but you do not need any other details), or if you actually needed the entire record with all its fields.

Happy to chat more feel free to connect over linkedin @mattcossu or via email matteo@crops-ag.com

Hi ​@sandra_k_o 

I’m curious as to which tables/automations are the major culprits. I use airtable to produce podcasts for my Airtable consulting business too. Likely a smaller scale but we have worked on lots of production/content systems.

We run into this sometimes and often it’s because of a few reasons:
1. The base architecture wasn’t set up properly which causes extra records/redundant information. The solution is to clean up the architecture. 
2. There’s really old data. For example, if you have tasks/details from a couple of years ago, you can use automation to capture the historical information into a text fields and delete the actual records. Ex. I could capture just the 17 tasks from a project/episode from 2 years ago because the likelyhood that I’ll actually need that info is low.

​​​​​​​​​​​​​​3.Syncs are not built in an effective way or people might be bringing it too much extraneous information. 

Happy to connect if you want me to have a look at your base. Cherry@claribase.com

Cherry

Thank you so much everyone for your very helpful and fast replies! The tool is still rather new to us so getting these tangible hands-on insights and suggestions are so valuable.

​@MatteoCrOps I've connected to you on LI and would be happy to get more insight to how you’re working with Airtable and how the summary fields works. ​@Emily.Ann I can loop you in if you’re also interested in learning more about this?

​@Blessing_Nuga thank you so much for this. I’m curious to understand your template model better. Does this approach limit the possibility to compare data between years? I also thought about archiving data into csv files, however that beats our overall aim to have a single source of truth, where we can make decisions based on historical data - being able to quickly sort through data and compare between the years. So storing data in separate CSV files don’t work for us, as we need the ‘live’ data at all times.

​@Cherry_Yang2 would love to continue the discussion and see what solutions you’ve built now that you also work with content/production of content. I’ll follow up with you on email!

Hi ​@sandra_k_o and everyone, 

Thanks ​@Cherry_Yang2, ​@Blessing_Nuga, ​@MatteoCrOps, ​@Emily.Ann for responding to the topic :)
 

This is such a timely discussion. We’ve been navigating these exact scaling challenges recently and wanted to share some insights from our side.

I believe this is a repeatedly asked question, especially by Enterprise users who manage multiple complex workflows through Airtable and are constantly trying to optimize their data structures to stay within limits while maintaining high performance.

Regarding the record limits, we’ve actually heard from colleagues at Airtable that there are plans to increase the base record limit to 1 million records per base. While the official date for this rollout hasn't been announced yet, it’s a promising sign for those of us treating Airtable as a true operational backbone.

That said, the advice we received, which we’ve found to be essential, is not to wait for that limit increase. Instead, they recommended focusing on a robust archiving workflow to ensure only "active" operational records live in the primary base. This keeps the performance snappy and prevents automation lag.

Here is how we’ve adjusted our architecture to handle the volume:

• Offloading "Logs": We realized a huge portion of our record count was taken up by change histories and audit logs. We have moved all "log" records into separate dedicated bases to clear up space in our main workflow engine.

• The BigQuery Hub: For long-term data insights and historical reporting, we are moving toward using Google BigQuery as our central data hub. By syncing both "live" operational records and "archived" historical data into BigQuery, we can build comprehensive dashboards (using Looker Studio) on top of that data.

This approach allows our team to keep Airtable lean for daily execution while maintaining a "single source of truth" for high-level insights without hitting those record limits.

Hope this helps give some ideas for your Airtable set up!

Hi ​@hamza.as.aslan,

Thanks for sharing this — it is super helpful context.

The logging setup you described makes a lot of sense, and I think the idea of offloading logs into separate bases is fairly straightforward. What I’m especially curious about is the broader architecture around multiple active bases and how you handle the interaction between them at a high level.

In our case, one of the main challenges is that different departments need to work in different bases, while still keeping data connected across workflows. For example, we might have one base dedicated to contract management and legal information, including summaries and structured metadata about contract terms, while another base is used by content teams to actively plan and manage shows. Ideally, those need to stay linked — not only for active shows, but also historically — so that contracts can still be connected to the content they relate to over time.

So I’d be really interested to hear, at a high level, how you’ve approached this:

• How do you structure the interaction between multiple active bases where different teams are actually doing their day-to-day work?
• How do you handle linking or syncing data between those bases without running into record-limit issues?
• How do you think about historic records in that setup — do you preserve cross-base relationships for archived data as well?

I’d also love to better understand the role BigQuery plays in your architecture.

We already have BigQuery running and connected to a lot of our sources, so one question for us is where you draw the line between Airtable and BigQuery. For example, for high-volume data such as performance or consumption/listening data on content, do you mainly handle that linking and modeling directly in BigQuery and keep Airtable out of it? Or do you try to route more of those sources through Airtable first to maintain one operational layer?

And related to that: do you mostly use Airtable as the operational workspace, with Looker Studio sitting on top of BigQuery for dashboarding and reporting? Or are there still specific use cases where Airtable itself functions as a dashboarding layer for your teams?

Would be amazing if you could share, as far as possible, a very general schema for how you think about the logic between active bases, archive, and BigQuery. That would be incredibly useful!

This is an interesting problem that I have dealt with on multiple occassions.

This is an interesting problem that I have dealt with on multiple occassions.

1 & 2: Structuring the bases: I’ve realized that for a business, a single bases having all the tables usually makes more sense in order to maintain proper relationships between tables and maintaing a single source of truth. A base is like a database instance. A business usually doesn’t have two disconnected databases. Hence, having multiple bases for the same businesses doesn’t go well in most cases.

Maintaining multiple bases makes sense if the tables across those bases have no relationship between them whatsoever.

So what are your other options if you are hitting the record limits?

Archiving: Yes, that’s a solid option. I create views in every table to filter out older records or processed records which will no longer be needed actively. Eg. if you have a table of tasks, then all the tasks older than 30 days which have also been completed can be filtered into an ‘Archive’ view. From there, you can take a monthly dump as csv and store them elsewhere, followed by deleting those records from airtable. 

You need to do this archiving only for high volume tables. Invariably, you will have certain tables that have disproportiantely higher records as compared to others. 

If you hit the limits even after archiving regularly and you still need to stick to Airtable, then splitting tables across multiple bases remains the only option and then building automations (often enabled by external tools like n8n/Zapier) to connect the data between those multiple bases.

I’m happy to have further discussion on this. Feel free to ping me.

Hey Sandra,

Apologies for the late response—higher ed has been incredibly hectic these days 😓.

Yes, the template model that we use is limited in that we only have records for the current academic year available in the base because records from previous academic years are archived and offloaded. However, we’re still able to maintain historical data for individual records through version logging, in which the most current “live” record is a duplicate of its predecessor, carrying over all previous data while tracking new changes.

For example, as the third version in a series, “Airtable Super Aerodynamics, MA_v3” contains all of the historical data of versions 1 and 2, as well as the most recent data for that record. This information is captured in a “record history” field that may look like this:

• Airtable Super Aerodynamics, MA_v3 created on December 1, 2025 to replace previous version with the following changes:
  • Title: “Airtable Aerodynamics, MA” → “Airtable Super Aerodynamics, MA”.
• Airtable Aerodynamics, MA_v2 created on September 1, 2025 for the most current academic year: 2025-2026.
• Airtable Aerodynamics, MA_v1 archived on August 31, 2025 as part of annual archiving process for academic year 2024-2025.
• Airtable Aerodynamics, MA_v1 created on September 1, 2024 for the most current academic year: 2024-2025.

While this versioning gives us a great 'audit trail' for individual records, you're right that for large-scale aggregate comparisons (like year-over-year trends), we would need to refer back to our exports. This allows us to keep the base streamlined while still ensuring we preserve the full data lineage for deeper analysis.

I may be able to lend some insights, if anything below interests you, feel free to shoot me a DM on here, or add me on LinkedIn (Joe Svingala) - otherwise there is way too much to write out for one response.

Since 2018/2019 I’ve been the lead strategist & system architect for our organization’s (Gaia, inc.) Airtable adoption/operational evolution. We are a large media company with over 900,000 active subscribers, with a media library of over 8,000 full length titles with new assets being published & distributed every day. 

At a high level, we took content operations from GSheets/Excel & turned it into a full suite application for all of our OPs associated teams (Production, Publishing (US/International), Digital Operations, Creative Services, Marketing, Merchandising, etc.). We have multiple environments with 100K+ records, we’ve actively used all automations available to us multiple times & worked around those limitations, we’ve extended our environment to be connected to all 3rd Party platforms we work with regularly, and have at this point built what most of our partners have agreed is one of the more thorough & complex media environments built in Airtable. 

If you’re curious about some (a very small sample) of what we’ve done in the media landscape, you can catch our presentation from Daretable 2024 here: