How do I put Postgres tables beside Vercel deploys?

Tares puts Postgres rows and Vercel log drain events on one timeline when both sources carry the same label value, marked as the key. Vercel events are keyed by project, so give your Postgres source a primary label named project that holds the same project names. Each changed row then lands next to the deployment traffic for that project.

How it works

Tares builds one timeline per key value. Two sources share a timeline only when both carry a label with the same name and the same value.

• Vercel deploys. The vercel source is a push source. You point a Vercel log drain at its ingest endpoint, and each log entry becomes one event. The key is project, taken from the payload’s projectName, else projectId. Events also carry environment, source, path, host, deployment and branch.
• Postgres tables. The postgres source polls a table incrementally on a cursor column, such as an autoincrement id or updated_at. It emits one event per new or changed row. A label marked primary turns an entity column into the key.
• The join. Choose the key both sources can carry. For Vercel it is project, so the Postgres source needs a label named project whose value matches the Vercel project name. If the whole table belongs to one project, use a constant label with const instead of a column.

This is the same pattern the AI SRE guide uses, where every source is keyed by one shared label so metrics, logs, alerts and deploys merge on one clock.

Set it up

1. Make Tares reachable from Vercel. Vercel delivers from its cloud, so the ingest endpoint must be publicly reachable. Use a deployed instance or a tunnel. A bare localhost daemon does not receive drains. For a local run, start Tares:

tares up

2. Create the Vercel source. Go to Sources, Add source, vercel. There is no required config, and the project (key), environment and source labels are pre-filled. Or use this object:

- name: web-logs
  connector: vercel
  config:
    labels:
      - { name: project, field: project, primary: true }
      - { name: environment, field: environment }
      - { name: source, field: source }

3. Add the drain in Vercel. Copy the ingest URL from the source page. In Vercel, open Team Settings, Log Drains, Add Log Drain. Set the endpoint to the ingest URL and the delivery format to JSON. Tares echoes back the x-vercel-verify header from Vercel’s verification request. If your Tares instance has auth on, add an ingest-scoped API key to the drain as a custom Authorization Bearer header.

4. Create the Postgres source with the same key. Go to Sources, Add source, Postgres. Enter the connection URL and choose Discover. It lists the tables it can see and proposes the cursor and labels from the columns. The Postgres must be reachable from the Tares host, and the dsn is stored as a secret. Make sure the key label is named project and reads a column that holds the Vercel project name:

- name: orders
  connector: postgres
  poll: 10s
  config:
    dsn: postgresql://user:pass@host:5432/appdb
    table: orders
    cursor_column: updated_at
    columns: id,project,status,amount,updated_at   # empty = every column
    labels:
      - { name: project, field: project, primary: true }
      - { name: status, field: status }

Set time_column if the row’s event time should come from a timestamp column other than the cursor.

5. Verify both sides. Open each source. On the Vercel source, Recent events shows entries arriving, and Fields shows which project values appear. On the Postgres source, Recent events shows rows on the next poll, and Fields reports each column’s coverage, so you can confirm the key column is reliably present. Check that the same project name shows up in both. If project reads sparse on the Vercel side, pick a denser field as the key, or slice by source or environment.

For more on Vercel logs and Postgres tables, see their connector pages.

What you get

• One timeline per project, with Vercel log entries and the Postgres rows that changed around them on the same clock.
• Deployment context on every Vercel event, through the deployment, branch, environment and source labels, so you can see which deployment was serving when a row changed.
• Your application’s source-of-truth data in the timeline, one event per new or changed row, without writing a pipeline.
• A shared key that any other source can join later, such as metrics or alerts labeled with the same project name.

When something else fits

• If your Postgres table has no column that matches the Vercel project name, use a constant project label when the table belongs to a single project, or add a column that holds the name.
• If you need explicit deploy events with a commit and author, post them from your CD pipeline to a webhook source, keyed by the same label.

Related