PostgreSQL

The Webflow CMS holds structured content in Collections. User-specific records, searchable directories, cross-table joins and similarity search over embeddings need a relational database behind the site, often PostgreSQL. Custom code on a published page runs in the visitor's browser. That is the wrong place for a database connection or credentials. The two systems need a bridge before any row can reach a page.

PostgreSQL stores the relational data, and Webflow lets you design how that data looks on the site. Rows become CMS items that render in a Collection List, form submissions land as rows in your own tables, and a Webflow Cloud app can query PostgreSQL on every request. The CMS stays the editing surface for marketing content while PostgreSQL carries the data that outgrows it.

This integration fits developers and agencies building directories, property portals or member areas on a Webflow front end. Marketing teams use it to keep the on-site catalog in sync with the production database without manual CMS edits. Founders shipping an MVP get a Webflow site, a relational store and an API layer without a separate frontend build.

How to integrate PostgreSQL with Webflow

What is PostgreSQL? PostgreSQL is an open-source object-relational database system that uses and extends SQL. It grew out of the POSTGRES project at UC Berkeley, which began in 1986, and it runs on all major operating systems. Its jsonb type stores JSON in an indexable binary format.

Teams pair PostgreSQL with Webflow when content needs relational structure or grows past a single Collection. Our Supabase integration page shows one pattern on a hosted Postgres, where Supabase Database Webhooks call an Edge Function that pushes row changes into CMS Collections. Every route keeps the CMS and adds a database alongside it.

• Whalesync mirrors PostgreSQL tables into CMS Collections through a hosted two-way sync, without writing code.
• Form webhooks, CMS CSV import and Code Embed cover one-way data moves and client-side display through an HTTP layer.
• Zapier, Make, n8n, and viaSocket connect Webflow triggers to PostgreSQL rows and back without running a server.
• The Webflow Data API and a PostgreSQL driver give you full control over sync logic, but require server-side code, which can run on Webflow Cloud next to your site.

Most implementations combine two or more of these methods depending on the complexity of the setup.

Sync PostgreSQL tables with the Webflow CMS through Whalesync

No Marketplace app is named PostgreSQL, so every route runs through a third-party tool or your own code. The closest no-code match is Whalesync, whose listing names Airtable, Notion and Google Sheets but whose documentation adds a Postgres connector. It runs a two-way sync between a PostgreSQL table and a CMS Collection, so an edit on either side lands on the other. Use it when a non-developer owns the data and the goal is CMS items, not a custom app. You need a PostgreSQL connection URI and a Webflow site you can authorize.

To set up the integration:

1. Open the Whalesync listing, click Add to site, choose the site, then Authorize app.
2. In Whalesync, connect Postgres using the database connection URI. Every synced table needs an auto-generated primary key.
3. Connect Webflow through OAuth. The Webflow connector maps the site to a base and each Collection to a table.
4. Map the PostgreSQL table to the Collection and start the sync.
5. Publish the site. Synced changes stay unpublished until you do.

Once running, the sync works in both directions: a row edited in PostgreSQL rewrites the CMS item, and an item edited in the CMS rewrites the row. Whalesync treats the authorized site as a base and each Collection as a table. After a Collection structure change, such as a new field, republish the site so syncing keeps working.

Xano is an alternative if you want an API layer instead of a CMS mirror. Its External Database Query function reads an external PostgreSQL by connection string. BuildShip also has a Marketplace listing, and its Postgres nodes fetch and insert rows inside low-code workflows.

Move data with CMS import, form webhooks and Code Embed

Three native Webflow features move data to or from PostgreSQL without a sync service. CMS import takes a CSV that PostgreSQL's COPY command writes. Form settings send each submission to a webhook URL that your endpoint turns into a row. A Code Embed fetches rows from an HTTP layer over the database and renders them client-side. Each one covers a single direction, so pick by where the data starts.

Import PostgreSQL rows into a Collection with CSV

The COPY command writes a table or a SELECT result to a file in text, csv or binary format, and psql's \copy runs the same export from the client side. The CMS importer reads that CSV and creates one item per row. This is the right path for a one-time load or an occasional refresh of a few thousand rows.

To import a table:

1. Export the table with COPY in csv format, or \copy in psql, including a header row.
2. In Webflow, open the CMS panel, select the Collection and click Import.
3. Drag in the CSV, confirm the header row, then click Continue.
4. Map columns. Matching headers map automatically; for the rest choose Create new field, Map to existing field or Do not import.

The CMS import article sets the constraints: a 4 MB file cap, Name and Slug under 256 characters, direct URLs for images, and semicolon-separated values for multi-image and multi-reference fields. Number columns can't contain letters, symbols or commas. To update existing items, export the Collection first and keep its "Item ID" column so the importer can link rows to items. Webflow also offers to create a pre-import backup that you can restore from Site settings > Backups.

Send form submissions to PostgreSQL with a form webhook

Every Webflow form can deliver to Webflow storage, email, a webhook, a connected app or a custom action. The form webhook posts each submission to a URL you control. Your endpoint reads the JSON and inserts a row. If Webflow storage stays selected too, submissions also appear in Site settings as a backup.

To route submissions:

1. Select the form and open the Settings panel.
2. Click the add icon next to Send to, choose Webhook, paste your endpoint URL and click Save.
3. Copy the Secret key Webflow shows once after you save and store it with your endpoint's other secrets; the endpoint needs it to validate each request's signature.
4. Parse the form_submission payload, which carries name, siteId, data, schema, submittedAt, id, formId and formElementId.
5. Insert the data map into your table, using id as the unique key.

A site-wide alternative lives under Site settings > Apps & integrations > Webhooks, where Form submission is a trigger type, though Webflow's webhooks guide notes that webhooks created in the dashboard don't include signature headers. A custom action is different: submissions sent that way aren't stored in Webflow and can't be combined with email notifications. The free Starter Site plan stops collecting after 50 total submissions, and that count doesn't reset.

Display PostgreSQL data on a page with a Code Embed fetch

A Code Embed runs HTML, CSS and JavaScript in the visitor's browser, with a 50,000-character limit and no server-side languages. It can't open a PostgreSQL connection, and it must never hold a connection string or database password, because every visitor can read the page source. Webflow's Code Components FAQ tells code components to call public APIs only, without auth tokens or secrets. The same rule fits a Code Embed, so point it at an HTTP layer in front of the database. PostgREST serves a RESTful API from an existing PostgreSQL database. Supabase exposes the same thing at https://<project_ref>.supabase.co/rest/v1/. The Neon Data API serves PostgREST-style routes such as /rest/v1/posts.

To render live rows:

1. Put an HTTP layer in front of the database and expose only the tables the page needs.
2. Lock down rows. On Supabase, grants control table access and row-level security controls rows; with RLS on and no policies, a publishable key reads nothing.
3. Add a SELECT policy for the anon role that exposes only the public rows of listings.
4. Add a Code Embed from the Add panel and fetch with the publishable key, as in this snippet:

<div id="listings"></div>
<script>
  fetch("https://<project_ref>.supabase.co/rest/v1/listings", {
    headers: { apikey: "sb_publishable_xxx" }
  })
    .then((res) => res.json())
    .then((rows) => {
      const el = document.getElementById("listings");
      rows.forEach((row) => {
        const item = document.createElement("div");
        item.textContent = row.name;
        el.appendChild(item);
      });
    });
</script>

Publishable keys (sb_publishable_xxx) are safe to expose; secret keys bypass RLS and belong on a server only. For a script shared across pages, put it in the site's head and body code under Site settings > Custom code, where each field also caps at 50,000 characters.

Connect PostgreSQL and Webflow with Zapier, Make, n8n or viaSocket

Zapier, Make, n8n and viaSocket each publish a Webflow connector, a PostgreSQL connector and a pairing page.

The documented triggers and actions pair up like this:

• Webflow New Form Submission → PostgreSQL New Row, which is Zapier's most popular template for this pairing and viaSocket's Insert row example.
• Webflow New Order or Updated Order → PostgreSQL New Row or Update Row in Zapier.
• Webflow Watch Events → PostgreSQL Insert row in Make, whose Webflow app also lists Item Create, Update, Publish and Delete modules.
• PostgreSQL New or Updated Row → Webflow Create Item, Update Item or Update Live Item in Zapier, the path for keeping a live price or stock figure current.
• PostgreSQL insert, update or delete → Webflow Create or Update in n8n, through the Postgres Trigger and Webflow node.
• Webflow Collection Item Created, Changed or Deleted → PostgreSQL row, from the n8n Webflow Trigger or viaSocket's item triggers.

These platforms connect from their own servers, so the database must be reachable from outside your network, with the firewall open on port 5432 or your custom port. Allowlist the static IP ranges in Zapier's PostgreSQL article. Make publishes regional egress IPs, and n8n Cloud shares its addresses across instances, so an allowlist there never replaces authentication.

Each platform watches PostgreSQL differently, and that shapes which direction works well. Zapier's New Row trigger polls a limited batch of recent rows, so a large bulk insert can slip past it. Make's PostgreSQL app has Select, Insert, Update, Delete, Execute a query and Execute a function modules but no trigger, which makes it a Webflow-to-PostgreSQL tool unless you schedule a query. n8n's Postgres Trigger creates a real trigger on your table, so the connecting user needs permission to create and execute triggers and procedures.

Build with the Webflow Data API and a PostgreSQL driver

PostgreSQL ships no HTTP or REST API. Its client interfaces are libpq, ECPG, large objects and the information schema, and every other language driver is an external project speaking the same wire protocol. That means a sync is server-side code: a worker that reads PostgreSQL through a driver, then calls the Webflow Data API over HTTPS with a bearer token. This path suits developers who need field mapping, retries and idempotency that no connector gives them. Webflow Cloud or another serverless host suits request-driven sync. A persistent LISTEN worker needs a long-running process.

On the database side, libpq and the frontend/backend protocol carry queries over TCP, with a connection string shaped like host=localhost port=5432 dbname=mydb connect_timeout=10. On the Webflow side, the Data API serves CMS collections and form submissions at https://api.webflow.com under the /v2/ prefix, and webhooks push form submissions, CMS item changes, orders and site publishes to your endpoint as they happen. Authenticate Data API calls with a site token for one site or OAuth for multi-site or user-specific access.

Push PostgreSQL rows into the CMS as items

Create Items accepts up to 100 items per request, and Update Items the same, so a worker that batches rows stays well inside those limits. Each item needs fieldData.name and fieldData.slug, and the field types reference sets what each Webflow type accepts. A reasonable starting mapping is text to PlainText or RichText, numeric to Number, boolean to Switch and timestamptz to DateTime as ISO 8601. Reference fields take Webflow item id strings, so the worker keeps a PostgreSQL-key-to-Webflow-ID map table. Field validations can't be set through the API, so define them in Webflow.

To implement the push:

1. Read the Collection schema with GET /v2/collections/{collection_id} and build the column-to-slug map.
2. Create staged items with POST /v2/collections/{collection_id}/items/insert (cms:write). Items are drafts by default, and isDraft: false, as below, queues them for the next site publish. Without cmsLocaleIds, items land in the primary locale only.

{
  "items": [
    {
      "isDraft": false,
      "fieldData": {
        "name": "Acme Corp",
        "slug": "acme-corp"
      }
    }
  ]
}

3. Publish with POST /v2/collections/{collection_id}/items/publish, passing itemIds; publishing a draft sets its isDraft to false automatically. Or skip staging and create through POST /v2/collections/{collection_id}/items/live, which publishes immediately.
4. Apply later changes with PATCH /v2/collections/{collection_id}/items, up to 100 items at once. Updating a slug breaks every link to the old slug.

To detect changes on the PostgreSQL side, a row-level trigger can call pg_notify and the worker runs LISTEN on that channel. NOTIFY delivers only after commit, and the payload must be shorter than 8000 bytes by default, so send the primary key and let the worker fetch the row.

CREATE FUNCTION notify_company_change() RETURNS trigger AS $$
BEGIN
  PERFORM pg_notify('company_changes', NEW.id::text);
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER company_changed
AFTER INSERT OR UPDATE ON companies
FOR EACH ROW EXECUTE FUNCTION notify_company_change();

For a durable queue instead of a live session, logical decoding streams row changes through a replication slot once wal_level is logical. On Supabase, Database Webhooks wrap a table trigger that sends an HTTP request through pg_net after INSERT, UPDATE or DELETE, and an Edge Function can then call the Webflow endpoints above.

Store Webflow webhook events in PostgreSQL

Webhooks cover the reverse direction, from Webflow into your tables, without polling. Trigger types include form_submission, site_publish, collection_item_created, collection_item_changed, collection_item_deleted, collection_item_published, collection_item_unpublished, ecomm_new_order, ecomm_order_changed, ecomm_inventory_changed and comment_created. The collection_item_created payload carries id, siteId, workspaceId, collectionId and the full fieldData, so a mirror table stays current without a Data API read. Handle delete and unpublish events as row deletes or status flags keyed on the item id. Deliveries that don't get a 200 retry up to three more times at a 10-minute interval, and repeated failures deactivate the webhook.

To implement the receiver:

1. Register the hook with POST /v2/sites/{site_id}/webhooks, sending triggerType and url. The request needs the sites:write scope, and each site allows 75 registrations per trigger type. A webhook you create with a site token comes back with its own secretKey; store it, because it is the signing key. Webflow's guide notes that webhooks created in the dashboard, under Site settings > Apps & integrations > Webhooks, don't include signature headers, so create database webhooks through the API.
2. Verify each request. Read x-webflow-timestamp and x-webflow-signature, compute a SHA-256 HMAC of timestamp + ":" + JSON.stringify(request_body) keyed with that webhook secret, or with your OAuth app's client secret when an OAuth app created the hook. Never use the site API token itself as the key. Reject anything older than 5 minutes.
3. Upsert on the payload id, which is the item ID for collection-item events, so retries can't create duplicate rows. INSERT ... ON CONFLICT DO UPDATE makes the insert-or-update atomic even under concurrency.

INSERT INTO webflow_items (id, collection_id, field_data)
VALUES ($1, $2, $3::jsonb)
ON CONFLICT (id) DO UPDATE
SET field_data = EXCLUDED.field_data;

4. Return 200 before doing slow work. Queue the heavy processing after the response.

Store fieldData in a jsonb column; per the JSON types docs, it is faster to process than json and indexable, though it drops key order and duplicate keys. Treat the schema pages as authoritative for field names, since consolidated examples use archived and draft where the schema pages use isArchived and isDraft.

Run a PostgreSQL-backed app on Webflow Cloud

Webflow Cloud runs Next.js, Astro and Vite apps on Cloudflare Workers, and its environment variables are available at build time and at runtime. Its built-in storage is SQLite, a key-value store and object storage, not PostgreSQL, so the database stays external and the app reaches it over the network. Webflow's Node.js compatibility guide lists Node's net module among the APIs to avoid and points network calls at fetch, so a driver that holds raw TCP connections is a poor fit. Neon's serverless driver speaks the Postgres protocol over HTTP or WebSockets instead. This is the path for user-specific dashboards and gated content, where every request runs a query.

To build the app:

1. Create the PostgreSQL project and copy its pooled connection string. Neon's pooled string includes -pooler and is the one Neon recommends for serverless and edge functions.
2. Store the string as a secret environment variable in Webflow Cloud, never in a Code Embed or any other browser code.
3. Query from a Route Handler with the @neondatabase/serverless driver, whose neon() function sends each query as an HTTP request. Don't add export const runtime = 'edge' to the handler: Webflow Cloud builds Next.js with the OpenNext Cloudflare adapter, and OpenNext's setup guide says to remove that line.
4. Call the handler from the site through the app's mount path. For example, with an app mounted at /app, a Webflow form posts to /app/api/waitlist and a second handler serves /app/api/waitlist/count.

On Supabase, write a member area's access gate as a row-level security policy, so it runs inside PostgreSQL rather than in the app, and query with the publishable key, since a secret key bypasses every policy.

What you can build with the PostgreSQL Webflow integration

Integrating PostgreSQL with Webflow lets you run data-heavy pages on a Webflow front end without moving the whole site to a custom framework.

• Programmatic directories past Collection limits: GOMO Digital's Dialectica Origin keeps the marketing site in Webflow and runs an Astro app on the same domain, with the data in Postgres on Neon. GOMO Digital reports that the MVP shipped in under two months with 1,500+ company pages, and the architecture is built to pass 10,000 records without changing.
• Property portals with fast search: Value Added Tech's real-estate build moved 2,847 property records into Xano's PostgreSQL database behind a Webflow and Wized front end. Value Added Tech reports that paginated search dropped to under 200ms from the 3 to 8 seconds of the previous Make.com setup.
• Lead capture in your own tables: A Webflow form posts to a webhook, and a small endpoint inserts the data map as a row, keeping leads in the same database as orders and accounts. The same result comes from Zapier's Webflow New Form Submission → PostgreSQL New Row template for teams that don't want to host an endpoint.
• Members-only content with Supabase auth: Supasaito's TGVP update moved a members-only blog to a Supabase-powered membership system for more secure and efficient access control, while the team still edits the blog in Webflow's Editor.

To watch PostgreSQL rows update a page as they change, build the live view in our Supabase dashboard guide.