How do I put Postgres tables beside GitHub commits and pull requests?

Tares puts Postgres rows and GitHub commits and pull requests on one timeline when both sources carry the same label with the same value, marked as the primary key. Add a github source and a postgres source, give each a primary label with the same name, such as repo, and make sure the values match. Tares then shows a change in code and the rows that changed after it side by side.

How it works

Each source turns what it reads into events, and every event carries labels. Events that share the primary label value land on the same timeline. Two sources only meet when the label name and the value are identical.

• The GitHub connector labels every event with repo, whose value is owner/name, for example acme/checkout-api. It also adds action, number, author, branch, sha, title and more when they apply.
• With a personal token, each source polls one repository every 2 minutes and reports commits and pull requests opened, merged or closed. With the GitHub App, pushes, reviews, issues, releases and CI runs arrive as they happen.
• The Postgres connector polls a table and creates one event per new or changed row. A cursor column that only grows, such as id or updated_at, tracks progress. An entity column becomes the key through a primary label.
• The join is the label. If GitHub marks repo as primary and your table also exposes a repo label with the same value, both land on one timeline for that repository.

The Build an AI SRE guide uses the same idea: all its sources are keyed by one service label, so metrics, logs and alerts merge into one timeline per service.

Set it up

1. Pick the shared key. Choose a value that both sides can produce for the same thing, such as a repository name like acme/checkout-api. If your table has a column holding that value, you can use it. Without such a column, the two sources have no label in common and will not share a timeline.
2. Add the GitHub source. With a personal token, create a source per repository under Sources > Add source > GitHub, or use this config. The repo label is the primary key:

- name: checkout-api
  connector: github
  poll: 2m
  config:
    repo: acme/checkout-api
    credential: github
    labels:
      - { name: repo, field: repo, primary: true }

3. Add the Postgres source under Sources > Add source > Postgres. Enter the connection URL and choose Discover. Pick the table and the cursor column, then make sure the column that holds the shared value is pulled. Give it a label with the same name as the GitHub label and mark it primary. This example assumes a column named repo:

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

4. You can also ask a connected agent to set up the Postgres source: it discovers the tables, proposes the cursor and labels, runs a dry run, then creates the source.
5. Verify the key. On the Postgres source, Fields reports each column’s coverage, so you can confirm the key column is reliably present. Recent events shows rows on the next poll.
6. Open the timeline for the shared value and check that commits, pull requests and rows appear together on one clock.

What you get

• One timeline per repository, or per whichever value you chose, with code changes and data changes merged on one clock.
• A way to see which rows changed after a commit or a merged pull request, so a change in behavior is tied to the change that likely caused it.
• Pull request events with action values such as opened and merged, and sha, author and branch on each event, next to your application rows.
• Triggers that can watch both sources together. A trigger on the github source can filter on event_type, action and repo, and the same pattern works across sources keyed by the same label.
• The same wiring feeds the agent in the AI SRE setup, so an investigation starts from one correlated view instead of two separate tools.

When something else fits

• If your tables hold no value that matches a GitHub label, add such a column or pick a different shared key before connecting them. Without a common label the two sources stay on separate timelines.
• If you need pushes, reviews, releases and CI runs as they happen rather than polled commits and pull requests, connect GitHub through the GitHub App instead of a personal token.
• If you need to see only deploys beside your data, the AI SRE guide shows a webhook source that your pipeline posts to on every deploy.

Related