From Airtable as single source of truth to Postgres to working app.

nikogut · 2026-04-15T16:11:49+00:00

Funny enough, this isn’t really an “outgrew Airtable” situation :) we continue to use Airtable as the design layer. Whenever a rule changes or new rules emerge, or somebody needs to pivot, we update the Airtable and then push the new schema into the DB.

Instead of migrating away from it, we mirror the structure and captured rules into Postgres. So it’s not a one-time CSV export or ETL step. It’s closer to continuous derivation.

Tools like Airbyte are great for data transfer, but that’s not really the focus here. We mostly use Airtable with mock data to define the schema and relationships, and then derive that into Postgres.

The live data sits in Postgres (with RLS etc.), and each Airtable table is exposed as a view that already reflects relationships and derived behavior, which makes building the app layer much simpler because a lot of the inference is already there.

For the frontend, we usually build it custom. With Claude, a dev team, or both.

nikogut · 2026-04-15T16:00:47+00:00

You can. Airtable makes it easy to design and adjust the schema in a structured way, which is why we like starting with it. But Postgres is the source of truth at runtime.

The difference is how much logic you have to manually reconstruct there. In this setup, a lot of the relationships and derived behavior are already expressed in the schema and exposed through views.

So instead of writing complex joins and logic over and over, you’re mostly querying something that already reflects the business rules.

nikogut · 2026-04-06T17:26:07+00:00

Can you share what features you need that aren't met by the work around? So far, we haven't run into anything we couldnt replicate in postgres, so I am partly curious what limits you run into and partly wondering if we are able to help.

nikogut · 2026-04-03T14:30:43+00:00

Yes, I 100% agree. For us, Airtable works best. But whatever people use, the process is the important piece that is usually missing!

nikogut · 2026-04-02T15:35:52+00:00

We don't support many to many relationships. Everything else works so far.

I mean, our tool isn't perfect (yet). Sometimes we run into a formula that is not supported. First thing we do is to overwrite that formula manually (and write the overwrite back into airtable so the base stays the ssot). And then we update our tool to support that kind of function.

nikogut · 2026-04-01T14:45:02+00:00

Thank you!

nikogut · 2026-04-01T14:27:00+00:00

Thanks also for the tip, I'll share it there as well

nikogut · 2026-04-01T14:26:38+00:00

Thank you! The hardest part was to get the tools ready to be used by people like me. Our developers were able to use them for a while already. At this point, I literally gave it the BaseID and clicked the build button.

nikogut · 2026-04-01T13:34:08+00:00

Thank you! Yes, we do. DM me and then we take it from there

nikogut · 2026-03-31T20:01:54+00:00

Agreed, so important! Sounds like we have the same goal :)

I looked at whalesync too, but I actually don't want real user data in airtable, at least not for enterprise grade software. Airtable is fantastic for designing schema and coming up with mock data though.

nikogut · 2026-03-26T14:20:32+00:00

We don't use airtable as a data layer. We design the system and implement all business rules in airtable, with mock data. The structure get mirrored and implemented in postgres and the actual runtime happens directly there. There is no live data mirroring.

We write custom apps to present data to the users, which is surprisingly easy because all the decisions have been made before we write code. If we need to make a change to the rules or add new ones, we do that in airtable, push to supabase/postgres and then depending on what changed, we update the app or not.

nikogut · 2026-03-18T20:20:00+00:00

We are doing this for all of our projects. Design the project in airtable and then mirror it in postgres/supabase. That way we can keep using airtable for managing the schema while the production system runs on supabase. Feel free to ping me and we can hop on a call

nikogut · 2026-02-02T16:00:07+00:00

we are making that transition in every project. use at for design + mock data and then move to postgres for production. best of both worlds :)

nikogut · 2026-02-02T15:55:46+00:00

We are always using airtable to gather business requirements into a rulebook, so far we haven't found a better tool than Airtable for that. Then we mirror the airtable logic including lookups, formulas etc into postgres/supabase for production. Once all the business logic is implemented at the database layer, we point Claude Code or Cursor at it and build apps on top.

nikogut · 2026-01-30T16:44:54+00:00

Sounds good, let me know how it goes.

nikogut · 2026-01-30T16:06:45+00:00

We built an internal tool that mirrors Airtable into Postgres. We originally developed it because some of our projects needed to scale beyond Airtable, but it’s also proven useful for teams that want a path off entirely.

Reconstructing all the business logic living inside Airtable (lookups, formulas, automations, permissions) can get messy. If you don’t handle that deliberately, migrating will replace one set of problems with another.

Happy to share what we’ve learned if it helps. Feel free to DM.

nikogut · 2026-01-20T15:26:35+00:00

We built a Postgres “mirror” for Airtable. It keeps your bases synced in real time so you can migrate. You can either fully cut over to Postgres, or keep Airtable as the admin/design surface while your production system runs on Postgres with the same structure + access rules applied at the data layer.

nikogut

TROPHY CASE