Airtable Attachment Limits: File Sizes, Base Storage, and Workarounds

Airtable caps individual file uploads at 5 GB across all subscription tiers, but cumulative attachment storage is strictly bounded per base between 1 GB on Free and 1,000 GB on Enterprise Scale. As documented in Airtable's attachment field documentation, teams can upload virtually any standard file format into an attachment field, yet total storage consumption across all records in a base remains strictly governed by the workspace billing plan.

A common misconception is that upgrading an Airtable workspace creates a pooled storage reservoir shared across all bases in an organization. In practice, Airtable enforces storage thresholds on an isolated, per-base basis. When an organization upgrades an Airtable tier, the expanded attachment allowance applies separately to each base rather than forming a shared workspace reservoir. A media production base nearing its storage ceiling cannot draw from unused capacity in an adjacent lightweight CRM base. Once an individual base reaches its assigned storage ceiling, it enters an over-limit state regardless of available space across other workspace projects.

Individual file limits interact directly with base quotas. Airtable caps individual file uploads at 5 GB across all subscription tiers, yet an upload cannot exceed the cumulative capacity of the host base. On the Free tier, uploading a large video file into a base with lower cumulative capacity immediately pushes the base over its total allowance.

These limits reflect Airtable's primary architectural purpose as an in-memory relational application engine rather than an unstructured object store. Every record, formula, linked relation, and field value lives in server memory to deliver instant filtering, sorting, and interface rendering. While binary attachments are stored off-cluster in cloud object storage, the metadata, thumbnail previews, and relational indexes for every attached asset still consume operational memory and base bandwidth.

• AWS Lambda File Size Limits: Payload, Package, and Ephemeral Storage CapsAn AWS Lambda file size limit encompasses the execution constraints of AWS Lambda functions, specifically the 50MB...
• Excel File Size Limits: Documented Caps and Large Workbook WorkaroundsMicrosoft Excel enforces a 1,048,576 row cap per worksheet, Excel Online restricts browser editing to 100MB workbooks,...
• FastAPI Upload File Size Limits: Memory Spooling, Middleware, and Direct StorageFastAPI imposes no native file size limit, but Starlette spools multipart uploads in memory up to `1,048,576 bytes`...
• Notion File Upload Limits: Size Caps by Plan and Large-File WorkaroundsNotion limits individual file uploads to 5MB on the Free plan and provides unlimited file uploads with a 5GB maximum...
• Perplexity Spaces File Limit: Upload Caps, Supported Formats, and Storage WorkaroundsPerplexity Spaces enforces a 25MB per-file upload limit and a 50-document ceiling per project on Pro accounts. While...
• Cloudflare Upload Limits: Plan Caps, Error 413, and WorkaroundsCloudflare restricts client request bodies passing through its edge proxy to 100 MB on Free and Pro tiers, 200 MB on...

More on this subject: Agent File and Document Workflows (269 guides)

In late 2022, Airtable implemented an architectural security change that altered how external systems interact with attached files: all direct attachment download links now expire after a few hours. Prior to this change, attachment fields generated static, permanent Amazon S3 URLs. Developers and automation builders routinely used Airtable attachment fields as a content delivery network, embedding those public URLs directly into customer-facing websites, marketing emails, external portals, and third-party dashboards.

Under the current architecture detailed in Airtable attachment URL behavior guidance, Airtable separates attachment links into two distinct categories:

1. Attachment Viewer URLs: These URLs originate from the primary airtable.com domain and represent the interactive preview modal inside the Airtable web application. These links do not expire as long as the record and file remain in the base. However, viewing the file requires active user authentication and explicit collaborator permissions on the base or interface.
2. Expiring Download URLs: These URLs originate from the airtableusercontent.com domain and represent signed download links. Airtable attachment download URLs expire every few hours for security. Because download URLs permit direct file retrieval without requiring Airtable login credentials, Airtable automatically signs them with cryptographic expiration parameters that invalidate the link within two to three hours.

This expiration window creates immediate breaking failures for downstream integrations that rely on static URL references. An automation that pulls an attachment link from Airtable and writes it into an external database or CRM will find that the link returns an HTTP 403 Forbidden error before the business day ends. Similarly, webhooks that dispatch attachment URLs to asynchronous background workers or AI processing agents will fail whenever task processing queues experience latency exceeding two hours.

Airtable's official recommendation for external file distribution is unambiguous: teams must never treat Airtable attachment fields as permanent hosting endpoints. Any workflow requiring reliable, persistent file access must either fetch a fresh signed URL through the Airtable REST API at the exact moment of access or offload the file to an external storage system during initial ingestion.

The rapid adoption of autonomous AI agents and automated webhook pipelines has turned base storage exhaustion into an acute operational problem. When human teams manually attach mockups, contracts, and spreadsheets to records, base storage accumulates slowly over months or years. By contrast, an automated agent or webhook pipeline can generate and attach hundreds of megabytes of binary data in a single afternoon.

Consider an automated document triage pipeline: an inbound email trigger receives scanned PDFs, invokes an optical character recognition model to extract line items, creates a new record in an Airtable financial tracking base, and attaches the original PDF along with high-resolution image crops of every receipt. If an automation pipeline ingests dozens of vendor submissions daily, each carrying high-resolution documents and image crops, the base accumulates gigabytes of binary data within weeks. An automated pipeline rapidly exhausts per-base storage allowances that would otherwise take human collaborators years to fill.

When a base exceeds its storage threshold, Airtable applies several administrative consequences:

• The base header displays a red Over limits warning badge visible to all collaborators.
• Workspace administrators receive automated email notices warning of plan violations.
• While Airtable provides a grace period rather than instantly freezing operations, persistent overages eventually block record creation, form submissions, and automation executions.
• Team members cannot upload additional attachments to any table within the affected base until total storage drops below the plan cap.

The most painful trap for engineering teams is the revision history retention mechanism. When an automation hits an over-limit warning, a common reaction is to run a cleanup script that deletes old records or clears attachment fields. However, deleting records does not immediately release base storage.

To support snapshot rollbacks and accidental deletion recovery, Airtable preserves deleted records and previous cell values in base revision history. Depending on the plan tier, revision history persists from fourteen days on Free up to three years on Enterprise Scale. Because the underlying file attachments remain restorable from base history, Airtable continues counting their byte size against the base storage quota. Teams caught in this state must contact Airtable support or wait for background tombstone compaction to reclaim their allocated capacity.

Store and Index Files Beyond Airtable Base Limits

Create shared workspaces with persistent file storage, automatic semantic indexing, and consolidated MCP tooling for AI agents. Monthly plans start with a 30-day free trial.

Start 30-Day Trial

To avoid base storage exhaustion and the expiring URL trap, high-volume production architectures decouple structured relational metadata from binary file storage. Instead of storing multi-megabyte files directly in Airtable attachment cells, the database stores only metadata, including file names, MIME types, file sizes, and durable external URLs.

Teams evaluate several architectural patterns to implement this separation:

Raw Cloud Object Storage (Amazon S3 or Google Cloud Storage): Storing files in S3 buckets solves the raw capacity problem, providing petabyte-scale persistence at low byte costs. However, raw object stores lack built-in collaborative interfaces, document viewers, and team permission controls. Developers must build and maintain custom upload endpoints, handle presigned URL signing services, and implement separate security controls for non-technical team members who need to view project documents.

Consumer File Sync Tools (Google Drive, Dropbox, Box): Syncing folders to cloud drives provides familiar user interfaces for non-technical staff. However, programmatic agent integration remains brittle. API rate limits, complex OAuth refresh token flows, and desktop sync latency make consumer drives difficult to coordinate with autonomous AI agents that require deterministic, immediate file reads and writes.

Persistent Intelligent Workspaces: Modern agentic architectures employ shared persistent workspaces designed specifically for human-agent collaboration. Platforms like Fast.io provide organization-owned workspaces where files are stored with per-file version history, granular permissions, and branded share links that never suffer from two-hour URL expiration. Teams looking for dedicated storage for agents can connect their automations to an intelligent workspace where files stay versioned and accessible.

When an AI agent or automated webhook handles an incoming document, it uploads the file directly to a persistent workspace rather than stuffing binary data into Airtable. When Intelligence Mode is enabled on the workspace, the document is automatically indexed for full-text and semantic search. The agent can then interact with the workspace using a Model Context Protocol server to retrieve excerpts or citations, while writing only the permanent link and structured metadata back into standard text fields in Airtable.

The following Python example illustrates how an automation worker offloads a file to an external workspace API and writes the resulting durable reference to Airtable using the standard httpx library:

import httpx

AIRTABLE_API_KEY = "patYourAirtablePersonalAccessToken"
AIRTABLE_BASE_ID = "appBaseIdHere"
AIRTABLE_TABLE_NAME = "Documents"
STORAGE_ENDPOINT = "https://api.fast.io/current/workspace/ws_123/storage/root/addfile/"
STORAGE_API_KEY = "fastio_api_token_here"

def ingest_document(file_path: str, document_title: str):
    with open(file_path, "rb") as f:
        file_bytes = f.read()
    storage_headers = {"Authorization": f"Bearer {STORAGE_API_KEY}"}
    upload_response = httpx.post(
        STORAGE_ENDPOINT,
        headers=storage_headers,
        files={"file": (document_title, file_bytes, "application/pdf")},
        timeout=30.0,
    )
    upload_response.raise_for_status()
    file_metadata = upload_response.json()
    permanent_file_url = file_metadata["data"]["share_url"]
    airtable_headers = {
        "Authorization": f"Bearer {AIRTABLE_API_KEY}",
        "Content-Type": "application/json",
    }
    record_payload = {
        "fields": {
            "Document Title": document_title,
            "File Size Bytes": len(file_bytes),
            "Durable URL": permanent_file_url,
            "Storage Provider": "Fast.io Workspace",
            "Processed Status": "Indexed",
        }
    }
    airtable_url = f"https://api.airtable.com/v0/{AIRTABLE_BASE_ID}/{AIRTABLE_TABLE_NAME}"
    record_response = httpx.post(
        airtable_url,
        headers=airtable_headers,
        json=record_payload,
        timeout=10.0,
    )
    record_response.raise_for_status()
    return record_response.json()

By routing binary files to dedicated workspace storage, the Airtable base retains zero attachment bloat, record counts scale cleanly toward plan limits, and AI agents can query document contents through Model Context Protocol endpoints without running into context window bottlenecks.

Preventing unplanned base freezes requires active operational auditing, especially when multiple automations and team members contribute to a shared workspace. Establishing proactive hygiene practices protects production workflows from abrupt plan threshold violations.

First, monitor base storage consumption systematically. Workspace owners should regularly review the Base Settings menu and inspect the workspace settings dashboard. Airtable displays current record counts and attachment gigabytes against assigned plan ceilings. Setting a recurring calendar reminder to audit storage metrics monthly helps teams identify upload spikes well before reaching plan thresholds.

Second, identify high-consumption tables and attachment columns. In bases with dozens of tables, storage exhaustion is usually driven by one or two unmonitored attachment fields. Create a dedicated administrative grid view in each table that filters for records containing attachments. While Airtable does not natively display total megabytes per attachment field in summary bars, you can use an Airtable Scripting extension or external API audit script to calculate cumulative file sizes per table.

Third, establish an automated offloading schedule for aged records. Production records typically experience a predictable lifecycle: high interaction during active processing, followed by long-term archival where records are rarely modified. Instead of allowing inactive records with heavy attachments to sit in production bases indefinitely, build a scheduled automation that identifies records completed more than ninety days prior. The automation transfers the attached files to an external workspace folder, replaces the attachment with an external storage link, and clears the binary file from the attachment field.

Fourth, govern inbound public uploads. Because native Airtable forms do not provide a mechanism to limit individual file sizes or restrict file extensions, public forms represent an unmonitored entry point for base bloat. If external clients or contractors submit files through public forms, consider using specialized form builders like Fillout or custom web portals that enforce strict client-side file size caps before transmission. Teams evaluating long-term workspace architecture can start a 14-day free trial to test external document indexing and durable links.

Decoupling heavy file storage from relational records transforms Airtable from an overburdened binary repository into a nimble orchestration hub. Team members continue managing business logic, linked relationships, and pipeline views in Airtable, while high-volume assets remain safely versioned and searchable in dedicated workspace storage.