Airtable Base vs Table vs Workspace: How to Structure Your Data

Three words decide where every piece of data lives in Airtable: workspace, base, and table. They sound like jargon but they're really an architecture choice that affects performance, permissions, collaboration, and how painful it'll be to refactor when the business scales.

Pick the wrong container and you'll spend the next two years fighting your data model — building automations to copy records between places that should have been linked, or unable to share a slice of one base with a client because everything is mixed together. Pick the right one and the system grows with you.

This guide explains exactly what each container is, when to use which, and the patterns we recommend after building Airtable systems for hundreds of clients.

The Three-Layer Hierarchy

Airtable's structure is simple to describe and easy to get wrong in practice.

Records — the rows in your tables — are the fourth layer, but they're not a container, just the data itself. Inside records you have fields (columns) that hold the actual values.

Quotable fact: A single Airtable base can hold up to 100 tables and 50,000 records per table on the Team plan, but most production bases run best with 5 to 25 tables — beyond that, splitting into multiple bases connected by sync usually improves both performance and clarity.

What a Table Is

A table is one set of records of the same type. A Clients table has client records. A Projects table has project records. A table has columns (called fields in Airtable) that describe each record, and rows that are the records themselves.

Think of a table as answering one question: what is each row? If you can answer cleanly ("each row is a Project," "each row is an Invoice," "each row is a Customer"), it's a table. If the answer is "well, some rows are projects and some are invoices and some are customers," you have three tables crammed into one.

Use a new table when:

• You can name a clear entity type that the rows represent.
• The data has different fields than your existing tables.
• You want to link records to this set from other tables.

Don't use a new table when:

• The data is just an attribute of an existing entity (Status, Tag, Priority) — those become fields, not tables.
• The data is a one-off list that no other table references. Those can live in fields or a multi-select.

Tables relate to each other via linked records, which are how Airtable becomes a relational database instead of a stack of spreadsheets.

What a Base Is

A base is a relational database — a collection of tables that work together. A base has its own URL, its own collaborator list, its own automations, its own interfaces.

Inside a base:

• Tables can be linked with linked record fields.
• Lookups and rollups can pull data across tables.
• Automations can read and write across tables.
• Interfaces can combine views from multiple tables.

A base is the unit of cohesion. Everything inside one base belongs together. Crossing a base boundary requires sync, the API, or an automation — none of those are free.

Use a new base when:

• The data is independent of your other bases (a new team, a new product line).
• The audience is different and you need different permissions.
• The current base is hitting performance or record limits.
• The use case has independently changing schema and shouldn't drag others along.

Don't use a new base when:

• The data is relational to existing tables (you'll lose the ability to link records directly).
• The same team is working on it (more bases means more places to check).
• You just want a new table — that's what tables are for.

What a Workspace Is

A workspace is the container for bases. It's also where billing and team membership live. Every workspace has Owners, Creators, Editors, and so on, and that role applies as the default across every base inside.

Workspaces are the right level for organizing bases by:

• Organization or company — your internal stuff vs a client's stuff.
• Department — Marketing's bases vs HR's bases.
• Plan tier — bases that need Business features vs simpler bases that can stay on Team to save money.

Workspaces don't have linked records, automations, or shared data across them. They're a permissions and billing boundary, not a data boundary.

For more on how workspace permissions cascade to bases, see our permissions guide.

When to Add Another Table vs Another Base

This is the single most important architecture decision. Here's the question we ask on every client engagement.

Add a table when:

• The new data is an entity that exists in the same business domain.
• You want to link it to your existing tables.
• The same team works on it.

Add a base when:

• The new data is a different domain (CRM vs HR, ops vs finance).
• Different teams own it and need different permissions.
• The current base is over 50 tables, 50,000+ records in a single table, or feels slow.
• You'll need to expose this to a different audience.

Workspace Strategies

A workspace strategy is mostly a billing and access strategy. Here are the three patterns we see in production.

Single Workspace, Multiple Bases

For most small-to-mid businesses, one workspace is fine. All your team is in it; you have separate bases for CRM, project management, HR, finance. Workspace Owners are your leadership. Workspace Creators are your operations team. Each base gets its own collaborators on top.

This is the simplest model and the one we recommend for any business under 50 people.

One Workspace Per Client (Agency Pattern)

If you're an agency building Airtable systems for clients, give each client their own workspace, owned and billed by the client. You keep an agency workspace for your own internal tools.

This pattern has three big advantages:

1. The client owns their data — if they leave you, they take their workspace.
2. Billing is on the client's card, not yours.
3. Permission accidents in one client workspace can't affect another.

The cost is operational: you're now juggling many workspaces in your Airtable home screen. Use workspace naming conventions (Client – Acme, Client – Globex, Internal – Agency) to keep them sorted.

Departmental Workspaces (Enterprise Pattern)

For larger orgs, each department gets a workspace. Marketing's workspace holds marketing bases. HR's workspace holds HR bases. The advantage is that workspace-level permissions automatically scope: making someone a Creator in the Marketing workspace doesn't give them access to HR.

The downside is that cross-departmental data (a single canonical Customers table that both Marketing and Support need) requires two-way sync between workspaces. Plan for this from day one.

Splitting an Existing Base

A common pain point: you started with one base for everything and now it's a mess. How do you split it without losing data and relationships?

The process:

1. Audit the existing tables. Group them by domain — which tables relate to each other? CRM tables here, HR tables there, operations elsewhere.
2. Pick the cleavage point. The right place to split is where there are fewest cross-domain linked records. If your Clients table is linked to both projects and HR records, that's a hard split. If HR is mostly self-contained, that's an easy split.
3. Create the new base. Don't copy — move. Use Airtable's "Duplicate base" feature to clone the source, then delete what doesn't belong in each base.
4. Set up sync for shared references. Whatever stayed in the source base but is needed in the new base gets a one-way sync. Most often this is a Clients or People table.
5. Update automations. Anything that wrote across the old base now needs to be re-pointed at the new base or replaced with a cross-base automation via Make, Zapier, or the API.
6. Update interfaces. Any interface that referenced both domains has to be split or rebuilt.

This process is non-trivial. If you find yourself doing it more than once, you didn't think hard enough about the original architecture.

Planning for Scale from Day One

The cheapest time to fix architecture is at the start. A few rules of thumb that pay off later.

Estimate ten-year record counts. If your Projects table will have 500 projects this year and you grow 30% annually, you're at 6,500 in ten years. That's comfortable inside one base. If your Events table will hit 1M+ records, you need a different plan.

Separate transactional data from reference data. Transactional data grows forever (Invoices, Orders, Activities). Reference data is small and stable (Products, Categories, Office Locations). They have different scaling needs. Keep them clean in the model even if they live in the same base today.

Don't pre-split. It's tempting to start with five bases "for separation of concerns." Don't. Start with one base and add bases when you have a real reason. Cross-base relationships are always more work than in-base relationships.

Anticipate audience. If a customer or external partner will ever see this data, isolate the customer-facing portion into its own base from the start. Pulling customer data out of an internal mega-base later is painful.

Real-World Architecture Examples

A few patterns we've shipped for clients.

Marketing Agency. One workspace per client (5–20 clients). Each client workspace has 2–3 bases: a Production base (content, briefs, deliverables), a Reporting base (metrics, results), and an optional Client Portal base (Interface-only client access).

SaaS Company. Three workspaces: Internal Ops, Customer Success, Marketing. Internal Ops has a Customers base that one-way-syncs into Customer Success (for ticket context) and Marketing (for campaign targeting). Each workspace has its own automations and team.

E-commerce. Two bases: Catalog (products, suppliers, inventory) and Orders (orders, customers, fulfillment). They're linked by SKU not by direct record link, because Catalog needs to be insulated from order volume. A Reporting base syncs from both for dashboards.

Common Mistakes

We've audited many client bases, and the same patterns show up.

Putting everything in one table. Project Name, Client Name, Client Email, Client Phone, Status, Owner, Owner Email — those last few belong on Clients and Users tables. If you find yourself retyping the same client's information across rows, split.

Pre-splitting before you have data. Five bases on day one with three records each is overhead, not architecture. Start with one base. Split when something forces you to.

Mixing client-facing and internal data in one base. Even with field permissions, the schema itself leaks information. A client peeking at the base sees your internal column names, your messy automation table, your half-finished ideas. Put customer-facing data in its own base.

Linked records across bases. You can't have true linked records across bases. The closest equivalent is two-way sync, which is approximate. If two entities are tightly relational, they belong in the same base.

Not naming things deliberately. "Untitled Base" and "Table 7" become tech debt fast. Name every base, table, and field as if a new team member will read it tomorrow.

Where to Go Next

Workspace, base, table — these three containers are the foundation. Once you understand them, the day-to-day decisions about where new data should live become much easier.

For the next layer, our linked records guide covers how tables connect within a base, and the two-way sync guide covers how bases connect across a workspace. The permissions guide is the companion piece on how to control who sees what once your architecture is in place.

If you're considering plan tiers, the pricing guide explains which architecture features (table permissions, two-way sync, larger record limits) require Business or Enterprise plans. Airtable's own base structure documentation is a useful reference for definitions when onboarding a new collaborator.