Behöver ert företag hjälp med att implementera AI? Kontakta oss och få prisoffert här →
AI Skolan ›
januari 22, 2026

Airtable till PostgreSQL, migreringar att köra om

Rickard Andersson Partner, Nodenordic.se

Att exportera från Airtable ser enkelt ut tills du stöter på länkade poster, fälttyper och det fruktade löftet “vi fixar det i SQL sen”. Då blir det plötsligt en helg med CSV-städning, trasiga relationer och ett databasschema som inte matchar det teamet faktiskt byggde.

Det här arbetsflödet för Airtable PostgreSQL-migrering träffar först och främst ops-ansvariga och tekniska grundare, om vi ska vara ärliga. Men marknadsförare som underhåller stökiga baser känner det också, särskilt när rapporteringen börjar sega och Airtables gränser dyker upp vid sämsta möjliga tillfälle.

Du sätter upp en migrering som går att köra om, som mappar ditt schema, skapar tabeller, flyttar poster i batchar och returnerar en tydlig sammanfattning av en lyckad körning så att du kan lämna Airtable med lägre risk.

Så fungerar automationen

Här är hela arbetsflödet du kommer att sätta upp:

n8n Workflow Template: Airtable till PostgreSQL, migreringar att köra om

Varför det här spelar roll: Airtable-exporter fallerar när det skalar

I början är Airtable “databasen”. Sedan blir den er CRM, content-kalender, leveransspårare och interna adminhub på samma gång. När basen växer blir allt känsligt: synkar blir långsammare, API-gränser slår till och ni börjar betala mer bara för att hålla igång allt. Så ni exporterar. Och då börjar smärtan. Länkade poster blir kryptiska ID:n, flervalsfält mappar inte rent, bilagor tappas bort och du slutar ändå med att bygga om tabeller för hand i PostgreSQL. Än värre: du kan inte enkelt köra migreringen igen, så varje “vi testar igen”-försök kostar ännu en bit av tid och förtroende.

Friktionen bygger på.

  • Länkade poster överlever inte en vanlig CSV-export, vilket betyder att relationer byggs upp igen manuellt.
  • Fälttyper gissas fel, så datum, nummer och kryssrutor hamnar i Postgres som stökig text.
  • Du gör en migrering, hittar problem och inser att processen inte är repeterbar utan att börja om.
  • Teamet fortsätter redigera i Airtable under flytten, så din “slutliga export” är inaktuell nästa dag.

Vad du bygger: en omkörningsbar Airtable → Postgres ETL

Det här arbetsflödet ger dig ett ETL-system (extract, transform, load) som du triggar med en enda HTTP-förfrågan. Du skickar Airtable- och PostgreSQL-uppgifter i request body, och arbetsflödet validerar båda sidor innan något destruktivt händer. Sedan hämtar det ditt Airtable-schema, mappar tabeller och fält till Postgres-vänliga kolumner och skapar tabellerna automatiskt. Därefter hämtar det Airtable-poster och lägger in dem i Postgres i batchar, vilket håller migreringen stabil även när du har många rader. Till sist svarar det med ett tydligt lyckat-meddelande och sammanfattande statistik så att du ser hur många tabeller och poster som hanterades. Du kan också anropa separata endpoints för att lista skapade tabeller eller radera dem, vilket gör omkörningar trygga istället för stressiga.

Arbetsflödet startar vid en webhook-endpoint som du kan anropa från curl, Postman eller ett annat verktyg. Efter kontroller av uppgifter och schema transformeras Airtable-fälttyper (som enkelradig text, tal och kryssrutor) till PostgreSQL-motsvarigheter. Sedan skapas tabeller, data läggs in i chunkar och ett svar returneras som “3 tabeller, 152 poster behandlade”, så att du kan gå vidare.

Det här bygger du

Förväntade resultat

Säg att du flyttar en bas med 3 tabeller och ungefär 150 poster (ett vanligt “vi måste lämna Airtable nu”-läge). Manuellt exporterar du 3 CSV:er, återskapar 3 tabeller, mappar om fälttyper och lagar sedan länkade poster; det blir lätt runt 3 timmar när du räknar in att rätta misstag. Med det här arbetsflödet triggar du migreringen med en förfrågan (ett par minuter), låter batchningen köra i bakgrunden och får ett lyckat-svar när det är klart. Den största tidsvinsten är den irritations-tid som annars går åt till att bygga om schema och länka relationer igen.

Innan du börjar

  • n8n-instans (testa n8n Cloud gratis)
  • Alternativ för egen drift om du föredrar det (Hostinger fungerar bra)
  • Airtable som källbas (Base ID + token).
  • PostgreSQL som tar emot tabeller och poster (host, port, databas, användare, lösenord).
  • Airtable access token (hämta det från Airtables developer hub).

Kunskapsnivå: Medel. Du behöver inte koda, men du bör vara bekväm med att skicka en HTTP-förfrågan (curl eller Postman) och klistra in uppgifter i en JSON-payload.

Vill du att någon bygger detta åt dig? Prata med en automationsexpert (gratis 15-minuters konsultation).

Steg för steg

Ett webhook-anrop kickar igång allt. Du anropar arbetsflödets endpoint med en åtgärd som “Validate Airtable”, “Validate Postgres”, “Move”, “List tables” eller “Delete tables”. Det enda valet styr vad resten av körningen gör.

Uppgifter och indata valideras tidigt. Arbetsflödet kontrollerar att din Airtable-token kan komma åt basen du angivit, och verifierar dina PostgreSQL-anslutningsuppgifter innan det försöker göra några schemaändringar.

Schemat mappas och förbereds för Postgres. Det hämtar Airtables tabell-/fältdefinitioner, konverterar fälttyper till Postgres-motsvarigheter (text till VARCHAR, number till INTEGER, checkbox till BOOLEAN och så vidare) och förbereder en kolumnlista för skapande av tabeller.

Tabeller skapas och poster laddas i batchar. Airtable-poster hämtas, transformeras till det mappade formatet och infogas i PostgreSQL i chunkar med throttling så att du inte slår i payload- eller rate limits. När det är klart returnerar n8n ett strukturerat svar med status och sammanfattande statistik.

Du kan enkelt ändra vilka tabeller som migreras, hur fälttyper mappas eller var relationer hamnar utifrån dina behov. Se hela implementationsguiden nedan för alternativ för anpassning.

Steg-för-steg-guide för implementering

Steg 1: konfigurera webhook-triggern

Sätt upp inkommande webhook-endpoints som startar arbetsflödet och normaliserar den initiala payloaden.

  1. Lägg till noden Incoming Airtable Webhook som er primära trigger.
  2. Lägg till noden System Webhook Entry för anrop på systemnivå och koppla den till Forward All Data.
  3. Koppla Incoming Airtable Webhook till Configure Webhook Data, sedan till HTML Parser och till sist till Return Webhook Reply för att bekräfta mot Airtable.
  4. I Configure Webhook Data mappar ni inkommande fält som ni förväntar er från Airtable innan parsning i HTML Parser.

Tips: Låt Return Webhook Reply vara kopplad så att Airtable får ett snabbt svar och inte försöker igen med webhooken.

Steg 2: anslut den primära routningslogiken

Routa inkommande payloads till rätt gren baserat på användarens avsikt och typ av begäran.

  1. Koppla System Webhook Entry till Forward All Data och sedan till Route By Option.
  2. Konfigurera Route By Option med de alternativ ni vill routa (t.ex. validering av autentiseringsuppgifter, hämtning av schema, borttagning eller merge-åtgärder).
  3. Säkerställ att Route By Option skickar utdata till Postgres Credential Data, Assign Webhook User Data, Select Base For Deletion och Assign User Info 4 som i arbetsflödet.

⚠️ Vanlig fallgrop: Om Route By Option inte matchar era inkommande alternativvärden kommer arbetsflödet inte att följa rätt gren.

Steg 3: konfigurera validering av autentiseringsuppgifter och framgångssvar

Den här grenen validerar autentiseringsuppgifter och returnerar ett svar om lyckat eller misslyckat tillbaka till den som anropar.

  1. Koppla Postgres Credential Data till Branch Check och routa till Airtable Field Data för spåret som verifierar autentiseringsuppgifter.
  2. Koppla Airtable Field Data till Validate Credentials, sedan Flag Tables Found och sedan Send Credential Reply.
  3. Koppla Modify Postgres Fields till Verify Postgres Access, sedan Validate Success och till sist till Compose Success Msg eller Compose Failure Msg.
  4. Slå ihop resultatmeddelanden i Combine Responses och skicka svar via Send Credential Reply.

Steg 4: sätt upp hämtning av schema och mappning

Hämta schemadetaljer från Airtable, expandera poster och mappa fält till arbetsflödets interna struktur.

  1. Koppla Assign Webhook User Data till Validate Base Identifier och sedan till Fetch Schema.
  2. Från Fetch Schema kopplar ni till Expand Items och sedan till Set Global Vars.
  3. Fortsätt mappningsflödet från Iterate Records Batch till Map Field Schema, sedan till Transform Mapper och Branch Check B.
  4. När Branch Check B utvärderas som true, routa till Assign User Info och Generate Database, och sedan till Prepare Error Data.

Tips: Om ert schema ändras ofta, håll Fetch Schema och Map Field Schema slimmade för att undvika oväntade fältmissmatchningar.

Steg 5: konfigurera parallell batchbearbetning

Bearbeta poster i kontrollerade batchar för transformering och svarsgenerering. Det här arbetsflödet inkluderar parallell körning.

  1. Från Set Global Vars kopplar ni till Throttle Batch A.
  2. Throttle Batch A skickar utdata till både Iterate Records Batch och Iterate Records Batch 2 parallellt.
  3. Från Iterate Records Batch kopplar ni till Define Column List och Map Field Schema enligt kopplingarna i arbetsflödet.
  4. Från Iterate Records Batch 2 kopplar ni till Modify Field Set 3 och Retrieve Records för att fortsätta svarsförberedelsen.

⚠️ Vanlig fallgrop: Noderna Throttle Batch A och Throttle Batch C är inaktiverade. Om ni behöver hastighetsbegränsning, aktivera dem och konfigurera gränser.

Steg 6: konfigurera hämtning av poster och fältsvar

Hämta poster, mappa fält och svara med fältdata via flera webhook-svar.

  1. Koppla Retrieve Records till Branch Check A, och sedan till Expand Items 3 och Map Record Fields.
  2. Från Map Record Fields routar ni till Modify Field Set och sedan till Assign User Info 2 och Merge Records.
  3. Fortsätt från Merge Records till Iterate Records Batch 2 och sedan till Modify Field Set 3 och Send Credential Reply 2.
  4. Använd borttagningsflödet: Select Base For Deletion → Fetch Schema For Delete → Expand Items 2 → Throttle Batch C → Configure Fields → Iterate Records Batch 3 → Modify Field Set 2 → Reply Airtable Fields A.
  5. Slutför merge-svarsflödet: Assign User Info 4 → Merge Records 2 → Reply Airtable Fields B.

Steg 7: granska transformations- och hjälpnoder

Flera set- och code-noder hanterar transformationer, användarmetadata och sammanslagning av poster. Konfigurera dessa noggrant utifrån er datamodell.

  1. Granska alla noder Assign User Info och Assign User Info 2/3/4 för att säkerställa att användar-id:n och base-metadata mappas korrekt.
  2. Validera transformationslogiken i Generate Database, Transform Mapper, Merge Records och Merge Records 2 så att den matchar er Airtable-/Postgres-struktur.
  3. Bekräfta att fältuppdateringarna i Modify Field Set, Modify Field Set 2 och Modify Field Set 3 ligger i linje med det förväntade svars-schemat.

Tips: Med 25+ set-noder och 6 code-noder bör ni testa varje gren separat med exempel-payloads för att validera mappningarna.

Steg 8: testa och aktivera ert arbetsflöde

Kör end-to-end-tester från varje ingångspunkt och bekräfta förväntade webhook-svar innan ni aktiverar arbetsflödet.

  1. Klicka på Execute Workflow och skicka en testförfrågan till Incoming Airtable Webhook.
  2. Verifiera att Return Webhook Reply, Send Credential Reply, Send Credential Reply 2, Reply Airtable Fields A och Reply Airtable Fields B svarar med giltiga payloads.
  3. Testa systemspåret genom att trigga System Webhook Entry och bekräfta routning via Route By Option.
  4. När allt fungerar växlar ni arbetsflödet till Active för att möjliggöra användning i produktion.
🔒

Lås upp fullständig steg-för-steg-guide

Få den kompletta implementeringsguiden + nedladdningsbar mall

Felsökningstips

  • Airtable-uppgifter kan gå ut eller sakna rätt scopes. Om körningar misslyckas tidigt, kontrollera token i din Airtable developer hub och bekräfta att den har åtkomst till Base ID:t du skickar.
  • Om du använder Wait-noder eller extern rendering varierar processtiderna. Öka väntetiden om nedströmsnoder fallerar på tomma svar.
  • PostgreSQL-rättigheter ser ofta “bra” ut tills tabellskapandet börjar. Bekräfta att din databasanvändare kan CREATE TABLE och INSERT, och kör sedan endpointen “validate-postgres” igen innan du migrerar.

Nästa steg

Om du fortfarande samlar in data på flera ställen hjälper det att standardisera indata innan du migrerar. När teamet också behöver få projektdokument omvandlade till strukturerade poster kan ClickUp till Airtable, dokument omvandlade till felfria poster hålla källbasen mer strukturerad så att den senare flytten till Postgres blir smidigare.

För team som överväger ett alternativ till Airtable men inte är redo för SQL är Airtable till Baserow, formulär som håller sig synkade ett bra steg ner i komplexitet. Det minskar inlåsning utan att tvinga fram en full databasmigrering dag ett.

Behöver du att din Airtable-data driver distribution medan du migrerar? När publicering av innehåll ingår i samma operativa system hjälper Airtable till Postiz, publicera överallt med en uppdatering dig att hålla marknadsföringen igång medan engineering städar backend.

När du väl landar i Postgres kan du äntligen göra riktig livscykelkommunikation baserat på tillförlitliga tabeller. Om WhatsApp-uppföljningar är en del av er intäktsmotor passar Postgres + Gallabox: WhatsApp-uppföljningar som faktiskt fastnar bra, eftersom databasen blir er källa till sanning för triggers till outreach.

Om du dessutom migrerar för att ledningen vill ha tydligare rapportering, koppla på finans också. QuickBooks till Google Sheets, månadsvis balanshistorik ger dig korrekt formaterad månadsdata som du senare kan join:a med din Postgres-data för starkare dashboards.


Snabbreferens:

Snabba svar

Hur lång tid tar det att sätta upp den här automationen för Airtable PostgreSQL-migrering?

Cirka 30 minuter om du redan har din Airtable-token och dina Postgres-uppgifter.

Krävs kodning för den här Airtable PostgreSQL-migreringen?

Ingen kodning krävs. Du klistrar mest in uppgifter och skickar ett webhook-anrop från curl eller Postman.

Är n8n gratis att använda för det här arbetsflödet för Airtable PostgreSQL-migrering?

Ja. n8n har ett gratis alternativ för egen drift och en gratis provperiod på n8n Cloud. Cloud-planer startar på 20 USD/månad för högre volym. Du behöver också räkna in kostnader för Airtable och PostgreSQL-hosting (ofta den största kostnadsdrivaren, inte n8n).

Var kan jag hosta n8n för att köra den här automationen?

Två alternativ: n8n Cloud (hanterad, enklast att komma igång) eller egen drift på en VPS. För egen drift är Hostinger VPS prisvärd och hanterar n8n bra. Egen drift ger obegränsade körningar men kräver grundläggande serverhantering.

Kan jag modifiera det här arbetsflödet för Airtable PostgreSQL-migrering för andra use cases?

Ja, och det bör du troligen. Du kan ändra vilken åtgärd som körs genom att justera switchen “Route By Option” och sedan anpassa mapping-beteendet i stegen “Map Field Schema” och “Transform Mapper”. Vanliga justeringar är att hoppa över vissa tabeller, byta namn på kolumner för att matcha era namngivningsstandarder och lagra länkade poster som foreign key-liknande ID:n som applikationslagret kan lösa.

Varför misslyckas min Airtable-anslutning i det här arbetsflödet?

Oftast är det ett token-problem eller en mismatch i Base ID. Skapa om Airtable access token, bekräfta att den har åtkomst till den basen och säkerställ att du skickar rätt basidentifierare (många klistrar in en URL men arbetsflödet förväntar sig Base ID). Om det fallerar senare vid hämtning av poster kan det också vara rate limiting, så det hjälper att köra vid lugnare tider och låta batchningen vara aktiverad.

Vilken volym kan det här arbetsflödet för Airtable PostgreSQL-migrering hantera?

För de flesta småföretagsbaser (hundratals till några tusen poster) kör det utan problem eftersom inserts sker i batchar. Om du kör n8n med egen drift finns ingen exekveringsgräns, men stora baser kan kräva en kraftfullare server och längre timeouts.

Är den här automationen för Airtable PostgreSQL-migrering bättre än att använda Zapier eller Make?

Ofta, ja. Zapier och Make är utmärkta för lättviktiga automationer av typen “synka en post”, men en full migrering är mer än så: du behöver schemamappning, batch-inserts, förgreningslogik för åtgärder (move vs. list vs. delete) och förutsägbar felhantering. n8n passar bättre när du vill ha kontroll över flödet utan att betala extra för varje väg eller varje stor körning. Dessutom spelar egen drift roll här eftersom migreringar kan vara spikiga, och du vill inte behöva oroa dig för task-limits mitt i flytten. Om du är osäker, prata med en automationsexpert och rimlighetskontrollera planen innan du ändrar något skarpt.

Sätt upp det en gång, kör det så många gånger du behöver och sluta behandla migreringar som engångsmirakel. Databasklippet blir en repeterbar process, inte en brandövning.

Kontakta oss

Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.

Våra tjänster Om Node Nordic
×

Använd mall

Få direkt tillgång till denna n8n-arbetsflödes JSON-fil

Kopiera och importera JSON-arbetsflödet i ditt n8n-arbetsflöde