How to Make an App Like Airtable

Building a no-code database platform sounds deceptively simple until you're six months in and realising that the hardest part was never the spreadsheet view.

Airtable sits at an interesting intersection: it's a relational database, a UI builder, an automation engine, and an API platform, all packaged to feel like a spreadsheet. Replicating that requires more architectural discipline than most teams anticipate. This post walks through the core decisions you'll face if you're seriously evaluating building something similar.

What Does an Airtable-Like Platform Actually Consist Of?

Before writing a line of code, be precise about what you're building. "Airtable-like" covers a wide surface area.

The core primitives are:

• Bases and tables — logical groupings of structured data with user-defined schemas
• Fields — typed columns (text, number, date, single-select, multi-select, linked record, formula, attachment, and so on — Airtable has 30+ field types)
• Views — grid, gallery, kanban, calendar, Gantt, form — each a different rendering of the same underlying data
• Linked records — cross-table relationships that behave relationally but are presented non-technically
• Automations — trigger-condition-action workflows
• Public API — programmatic access per base

If you're building the full surface, plan for 18–24 months of serious engineering. If you're building a vertical slice (say, a no-code database for restaurant operations or logistics workflows), you can cut that significantly by restricting field types and views.

How Should You Model the Schema When the Schema Is User-Defined?

This is the genuinely hard problem. Users define their own tables and fields at runtime. You can't know what those look like at build time.

There are three common approaches:

EAV (Entity-Attribute-Value) stores each cell as a separate row in a key-value table. It's flexible but slow — queries that would be a single JOIN become multi-step aggregations. Airtable reportedly moved away from a pure EAV model as they scaled.

JSONB columns in PostgreSQL store each record as a JSON document with typed fields extracted at read time. PostgreSQL 14+ supports generated columns and partial indexes on JSONB paths, which recovers some query performance. This is the approach that makes the most sense for a new build in 2024.

Column-per-field in a per-table schema means you create actual PostgreSQL tables dynamically as users create bases. This gives you the best query performance and lets you use native types, but schema migrations become a coordination problem at scale. Dropping a user's field means an ALTER TABLE in production. That's manageable with a queue-based DDL system, but you need to build it.

Our recommendation for a greenfield build: start with JSONB in PostgreSQL. Add GIN indexes on the JSONB columns. Accept that complex multi-field sorts will be slower than native columns, and mitigate that with materialised views for common query patterns. Revisit dynamic-table schemas only if query latency becomes a real user problem at scale, not a theoretical one.

What Does the Frontend Architecture Look Like?

The grid view is the performance bottleneck. Airtable's grid renders tens of thousands of rows without lag. That's not a default behaviour in React.

You need virtual rendering. The canonical choices are react-window or react-virtuoso for list virtualisation, but a spreadsheet grid with both row and column virtualisation is more complex. TanStack Virtual (formerly react-virtual) handles two-dimensional virtualisation well and is actively maintained.

Beyond virtualisation:

• Cell editors need to be mounted outside the grid DOM to avoid z-index issues and reflow
• Collaborative editing requires operational transforms or CRDTs — Yjs is the practical choice here; it has mature bindings for React and handles offline sync
• Undo/redo across a shared document is non-trivial; model it as a command pattern from day one

The formula engine deserves its own callout. Airtable supports over 100 functions including IF, SWITCH, FIND, REGEX_MATCH, and cross-table lookups via LINKED_RECORD_SUM. Building this from scratch is a substantial project. Consider adapting HyperFormula (MIT licence) which implements a spreadsheet formula engine in TypeScript and handles dependency graphs and circular reference detection.

How Do You Handle Real-Time Collaboration?

If multiple users can edit the same base simultaneously, you need a synchronisation layer.

WebSockets are the transport. The pattern that holds up at scale is to broadcast change events from the server and let each client apply them optimistically, then reconcile if the server rejects them. This is where CRDTs earn their complexity cost.

Yjs with a y-websocket provider is a practical starting point. It handles merge conflicts without a central lock, and it compresses well for large documents. The tradeoff is that Yjs awareness state (cursors, selections) adds additional message volume — worth profiling before assuming it's cheap.

For the backend, you'll want a dedicated presence service separate from your main application server. A Node.js process using uWebSockets.js can handle tens of thousands of concurrent WebSocket connections on a single instance. Don't route WebSocket traffic through your REST API server.

Automations and Webhooks

Automations in Airtable are trigger-condition-action chains. Triggers include record creation, field changes, form submissions, and scheduled intervals. The execution model should be treated as a workflow engine, not a simple event listener.

Use a durable queue — BullMQ over Redis, or Temporal if you want full workflow durability with retries, timeouts, and visibility. Don't execute automation logic inline in your API handler. Async, always.

Webhooks to external services (Slack, email, HTTP POST to arbitrary URLs) need retry logic with exponential backoff, dead-letter queues, and per-user rate limiting. Plan for this at design time; bolting it on later is painful.

What's the Right Infrastructure Starting Point?

For a new platform targeting 1,000–10,000 active workspaces, a reasonable starting configuration is:

Layer	Choice	Notes
API	Node.js with Fastify	Lower overhead than Express; native TypeScript support
Database	PostgreSQL 16 on RDS	JSONB + GIN indexes; read replicas for query-heavy views
Cache	Redis 7	Session state, rate limiting, pub/sub for real-time
File storage	S3-compatible (AWS S3 or R2)	Attachment field storage
Search	PostgreSQL full-text first	Move to Elasticsearch only when tsvector falls short
Auth	Auth0 or Clerk	Don't build auth; buy it
Infra	AWS ECS Fargate	Container-based, no cluster management overhead

At 50,000+ workspaces, you'll need to think about database sharding by base or workspace, CDN-level caching for public views, and separating the formula evaluation service so it can scale independently.

How Long Will This Actually Take to Build?

Honest answer: longer than your first estimate.

A minimal viable version with grid view, five field types (text, number, single-select, linked record, date), one automation type, and a REST API is a 4–6 month project for a team of four engineers. That's assuming the team has built data-intensive frontend applications before.

Adding gallery, kanban, and form views adds 2–3 months. A formula engine with 20+ functions is another 2 months. Real-time collaboration is 3–4 months to do well. A complete Airtable clone is a multi-year engineering programme; Airtable itself took 4 years to reach Series A with a team focused entirely on the product.

The right question is not "can we build this" but "what vertical of this do we actually need." A purpose-built tool for your domain with 6 field types and 2 views will outperform a generalised Airtable clone for your users, ship in a third of the time, and be cheaper to maintain.

Conclusion

If you're building a general-purpose no-code database platform, start with JSONB schema storage, TanStack Virtual for the grid, Yjs for real-time collaboration, and Temporal for automations. Scope the first version to 5–8 field types and 2 views. Validate that users actually need the full surface before building it.

If you want a team that has built data-intensive, schema-flexible platforms and can help you scope this accurately, get in touch with Sodio.

FAQ

How much does it cost to build an Airtable-like platform? A focused MVP with a grid view, core field types, and a REST API typically costs £150,000–£250,000 in engineering time for a competent team of four over five to six months. A full-featured platform with real-time collaboration, automations, and multiple view types will run two to four times that figure.

Should I use PostgreSQL or MongoDB for a dynamic-schema database platform? PostgreSQL with JSONB is the stronger choice. It gives you the flexibility of a document store while retaining ACID guarantees, native JSON operators, GIN indexing, and compatibility with the broader PostgreSQL ecosystem. MongoDB's schema flexibility offers less advantage once PostgreSQL's JSONB capabilities are fully utilised.

Can I use an open-source Airtable alternative as a starting point? NocoDB and Baserow are both open-source and actively maintained. NocoDB connects to existing databases and is useful if your use case is a database UI layer. Baserow is a closer architectural match to Airtable. Both are good starting points for studying the architecture, and both support self-hosting, which may be enough without building from scratch.

What is the hardest part of building an Airtable clone? The formula engine and real-time collaboration are the two parts that most teams underestimate. Formula dependency graphs, circular reference detection, and cross-table lookups are genuinely complex. Real-time collaboration with conflict resolution requires careful CRDT integration. Both are solvable with existing libraries, but integration time is longer than it looks.

Do I need a separate search service from day one? No. PostgreSQL full-text search with tsvector columns handles most search requirements at early scale. You'll know you've outgrown it when you need fuzzy matching across millions of records with sub-100ms latency. At that point, adding Elasticsearch or Typesense is a well-understood migration path, not an emergency.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.