The list that isn't in your email tool

Where does your newsletter list live?

The honest answer, for most people, is "inside Mailchimp" — or inside the form tool, or inside a spreadsheet somebody exported once. The list belongs to whichever product captured it, and every other tool that needs it gets a copy that starts drifting immediately.

Turn it around

Put the list in a PostgreSQL table you own. Then:

• The form writes a row. Whatever captures the signup — a form builder, your own site, a support agent typing it in — creates a record through the REST API or a Zap.
• The email tool reads it. It isn't the owner any more. It's a consumer.
• So is everything else. Reporting, a SQL query, a dashboard, an agent. None of them need an export, because none of them are looking at a copy.

The difference shows up the day you change tools. Swapping the email provider costs you a Zap. Swapping it in the other arrangement costs you an export, an import, and whatever the export quietly dropped — the unsubscribe dates, the tags, the signup timestamps that came through as strings.

What makes this practical rather than aspirational

It only works if writing to your database is as easy as writing to the tool, which is what the Zapier integration is for. Create Row turns any Zapier trigger into a row in your table. Find Row looks one up. New Row lets your database start a workflow of its own.

And the data stays in your database throughout. Nothing is copied into Zapier and nothing is copied into SchemaStack — every call reads and writes the Postgres or MySQL instance you already run. That is the whole point of the arrangement and it is worth being literal about it.

Being straight about what I watched

This site's own subscriber list lives this way, in a table called Subscribers in a workspace pointed at our own database. There is a Zap that reads it every morning: a schedule fires, Find Row fetches from SchemaStack, and Gmail sends. It ran at 08:30 on the day this was written and each step reported success — a real pipeline, on production, not a diagram.

The production logs agree with it: successful authentication calls in the hundreds, a Find Row returning an actual subscriber record with Zapier's own _zap_search_was_found_status marker on it, and an update landing through the API.

Two things they do not show, both worth saying rather than eliding.

No form submission arrived as a new row while I was looking. The table's most recent signup predates that window by months, because this site is young and signups are rare. So the create path here is verified by the integration's test suite, not by traffic I watched go past.

And the daily Zap is triggered by a clock, not by the database. It could have been a New Row trigger — that exists, and it would mean the workflow ran when a signup happened rather than at half past eight. It isn't, and describing this arrangement as event-driven would have been the flattering version rather than the accurate one.

What it doesn't do (yet)

• You still need the tools. This arrangement doesn't send email, build forms, or replace anything — it changes which system holds the authoritative copy.
• A Zap is a moving part. Owning the database means the pipeline into it is yours to keep working. A broken Zap is a signup that silently didn't arrive, and nothing here monitors that for you.
• Triggers poll. A row written to your database reaches a downstream tool on the next poll, not immediately.
• No deduplication on write. Create Row creates. The same email submitted twice is two rows unless you add a unique constraint — which you can, because it's your schema. (Bulk imports grew a real answer on 2026-08-27: name your match columns and a re-import skips or corrects existing rows instead of duplicating them. Single writes through a Zap still simply create.)
• Unsubscribes are yours to model. No tool will manage consent state in your table for you; that's a column and a process you design.
• One workspace per Zapier connection, so a list split across workspaces means several connections.

If what you want is the mechanics rather than the argument, the integration post covers the triggers and actions, and the compatibility list covers what SchemaStack understands about a database you point it at.