How do I read Postgres tables next to logs from Vercel projects when an AI SRE investigates?

Tares puts Postgres rows and Vercel log lines on one timeline when both carry the same label value, such as the project name. Add a vercel source and a postgres source, give both a label with the same name, and one read of that value returns the log lines and the rows together. The AI SRE then investigates with your application’s data beside the logs.

How it works

Each connector turns its input into events, and labels decide which entity an event belongs to.

• The vercel connector is a push source. You point a Vercel log drain at the source’s ingest endpoint, and Tares stores one event per log entry. The entity key is project, taken from the payload’s projectName, else projectId. The labels environment, source, path, host, deployment and branch come with it.
• The postgres connector is a poll source. It reads a table incrementally on a cursor column, such as an autoincrement id or updated_at, and stores one event per new or changed row. A label with primary: true makes one column the entity key.
• The two sources share a timeline when the label carries the same name and the same value on both sides. If Vercel logs for the project checkout arrive with project set to checkout, a Postgres row whose project label is checkout lands next to them. One read of that value returns both.

The Postgres connector does not add a project label for you. You declare it from a column of your table, so the table needs a column that holds the same value your Vercel logs carry. For per-customer data, key the Postgres source on a column such as tenant_id instead, and the same rule applies: the log lines need to carry that label value too.

Set it up

1. Create the Vercel source. In Sources → Add source → vercel there is no required config, and the project, environment and source labels are pre-filled. As YAML:

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

Copy the ingest endpoint shown on the source page. You can also ask a connected agent to create the source and give you the ingest URL. See the Vercel logs connector for the full label list.

2. Add the log drain in Vercel under Team Settings → Log Drains → Add Log Drain. Set the endpoint to the ingest URL and the delivery format to JSON. Vercel delivers from its cloud, so the endpoint must be publicly reachable. Use a deployed instance or a tunnel, because a bare localhost daemon does not receive drains. Tares echoes back the x-vercel-verify header from Vercel’s verification request. The sender uses a Bearer Authorization header holding an ingest-scoped API key, needed only when Tares has auth on.

3. Create the Postgres source in Sources → Add source → Postgres. Enter the connection URL, press Discover, pick the table, and choose the columns to pull. Declare a label whose name matches the Vercel label and whose field is the column holding the same value:

- 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 }

The dsn is stored as a secret. The cursor column must only ever grow, and Discover picks it. The Postgres table connector lists every field.

4. Check both sides. On each source, Recent events shows what arrived and Fields shows each field’s coverage. On the Vercel source, confirm which project values appear. If project reads sparse, pick a denser field as the key, or slice by source or environment. On the Postgres source, confirm the key column is reliably present.

5. Ask your agent to investigate. Name the shared value, for example the project checkout, and the read returns Vercel log lines and Postgres rows on one timeline. The AI SRE guide covers how an investigation uses that timeline.

What you get

• One read of a shared label value returns the Vercel log lines and the Postgres rows together, in time order.
• Your application’s source-of-truth data, such as order status changes, sits beside the runtime logs from the same project.
• A single Vercel drain can carry several projects, and each appears as its own entity, so each project gets its own combined timeline.
• Postgres rows arrive on the next poll after you save the source, and Vercel entries arrive as traffic flows.
• Triggers can watch both sources, because each Postgres column you pull is a field you can label.

When something else fits

• If the data you want next to the logs comes from a JSON API rather than a database, the HTTP API (poll) connector reads an endpoint on a schedule and takes the same label approach.
• If your Tares host cannot be reached publicly, Vercel cannot deliver the drain. Use a deployed instance or a tunnel before adding the Postgres side.

Related