Postgres action — the differentiator

Write Stripe events to Postgres, your database

Pipe any Stripe event straight into your own Postgres database. Templated columns, upserts, retries that won't write the same row twice. The action Stripe will never ship natively.

Free trial · From $19/mo · No credit card required

The problem

Every serious SaaS eventually needs Stripe data in its own database. Not Stripe's data warehouse, not a third-party CDP, the Postgres instance with the user table that has a foreign key into billing. The usual paths are both heavy: stand up a custom webhook handler with signature verification, retries, and a schema you maintain by hand; or pay Fivetran several hundred a month to mirror the entire Stripe object model on a delay. Either one is overkill for a workflow step.

The Postgres action is the one Stripe will not ship natively. Point it at your database with a connection string (sslmode=require), map Stripe event fields to columns with JSONata, set an upsert key, and write. It runs as a step inside the Stripe Workflow builder. The data lands in your schema, in your column names, deduped on Stripe's invocation id. That is the whole differentiator.

How the Postgres action works

  1. 1

    Add your connection string

    Paste a postgres:// URL into the action. Outbound requires sslmode=require, stores the string encrypted per account, and connects through a pool. Tested against Neon, Supabase, RDS, Crunchy Bridge, Railway, Fly Postgres, and self-hosted.
  2. 2

    Map event fields to columns

    Configure the target table and a column-to-JSONata mapping. Outbound infers column types from the database and validates the mapping on save. Type coercion handles numbers, timestamps, jsonb, and booleans without code.
  3. 3

    Set an upsert key (optional)

    Pick the column (or columns) that uniquely identifies a row, usually a Stripe id. Outbound generates an ON CONFLICT clause so re-running a workflow updates instead of inserting a duplicate. Skip the key entirely and every execution appends a new row.
  4. 4

    Publish and watch your tables fill

    The action writes one row per Stripe invocation. The execution log shows the row count, write latency, and any constraint violations from Postgres. Your existing queries return live Stripe data within seconds of the event firing.
// outbound.postgres step in a Stripe Workflow
{
  trigger: 'invoice.paid',
  action: 'outbound.postgres',
  config: {
    connection_string_secret: 'PG_URL',
    table: 'stripe_invoices',
    upsert_key: ['stripe_invoice_id'],
    columns: {
      stripe_invoice_id: '{{invoice.id}}',
      customer_id:      '{{customer.id}}',
      amount_paid:      '{{invoice.amount_paid}}',
      currency:         '{{invoice.currency}}',
      paid_at:          '{{$fromMillis(invoice.status_transitions.paid_at * 1000)}}',
      raw:              '{{$}}'  // store full event as jsonb
    },
  },
}

Example workflow configuration

Screenshot of the Postgres action config inside the Stripe Workflow builder. Shows a connection string field with masked characters, a table picker dropdown listing tables from the connected database, a column-to-JSONata mapping grid with type indicators (text, int, timestamp, jsonb) next to each column, and an upsert key multi-select with two columns chosen.

Your schema. Your database. Stripe Workflows writes directly into it with type checking and upsert support.

Outbound vs custom webhook handler

Outboundcustom webhook handler
Hosted infrastructure to maintain
Signature verification + retriesbuilt-inyou build it
Idempotent on Stripe invocation idyou build it
Setup time≈5 minutes1–2 days
Pricing modelFrom $19/mo flatHosting + dev time
JSONata column templating
Lives inside the Stripe Dashboard

Frequently asked questions

Which Postgres flavors are supported?+
Anything that speaks the standard Postgres wire protocol over TLS. We test against vanilla Postgres 14, 15, 16, plus Neon, Supabase, AWS RDS, Crunchy Bridge, Railway, and Fly Postgres. CockroachDB and Aurora Postgres work but are best-effort.
How do you handle schema changes?+
Outbound reads the column list and types on every config save. If a column is dropped or its type changes incompatibly, the action fails fast on the next workflow publish rather than silently inserting garbage. You add a column, save, you're back online.
Can the connection go through a VPC or private network?+
v1 connects from a fixed set of Outbound egress IPs over public TLS, suitable for any provider that offers an SSL endpoint. Private-network access via PrivateLink or VPC peering is on the Pro roadmap; talk to support if you need it sooner.
What about transactional writes across multiple tables?+
The action writes one row to one table per execution. To write to multiple tables transactionally, point the action at a Postgres function (call_target: function) and let Postgres run the multi-statement transaction. This keeps the heavy schema knowledge in your database, not your workflow.
How do you keep credentials safe?+
Connection strings are encrypted at rest with a per-account key. They're never returned in the dashboard once saved, never logged, and only readable by the worker that executes your workflow. Rotate any time — the action picks up the new string on next save.