How do I bring Postgres tables into an AI SRE’s context?

Tares brings a Postgres table into an AI SRE’s context with the postgres connector, which polls the table and stores one event per new or changed row. You give it a connection URL, a table and a cursor column that only grows, and your application’s own data appears in the timeline next to your other sources. If the data sits behind a JSON API instead of a database, the http_poll connector polls that endpoint and stores one event per item.

How it works

The postgres connector reads a table incrementally, so each poll fetches only what is new since the last one.

• Cursor column. A column that only ever grows tracks progress. An autoincrement id catches inserts. An updated_at column catches inserts and updates.
• One event per row. Each new or changed row becomes one event.
• Entity key. A label marked primary, such as tenant_id, makes that column the entity key for the table’s events.
• Discovery. Given the connection URL, Tares lists the tables it can see. When you pick one, it reads the columns and proposes the cursor, the entity key and the labels.
• Credentials. The dsn is stored as a secret. The API redacts it and catalog exports omit it.

The Postgres must be reachable from the Tares host. The driver ships with Tares, so there is nothing extra to install. The full field list is on the Postgres table connector page.

For an endpoint that returns JSON, the HTTP API (poll) connector works the same way in spirit. Tares calls the endpoint on the source’s schedule and stores one event per item in the reply. A single object is one event, and a list is one event per entry.

Set it up

1. Make sure a Postgres is reachable from the host that runs Tares, and have a connection URL ready in the form postgresql://user:pass@host:port/dbname.
2. Pick how you want to add the source:
   • Ask a connected agent, for example: use tares to ingest the orders table, keyed by tenant_id. The agent runs discovery to list the tables and propose the cursor and labels, then a dry run that fetches sample rows, then creates the source.
   • In the UI, go to Sources → Add source → Postgres, enter the Connection URL, press Discover, pick a table and choose which columns to pull. All columns are pulled by default.
3. Review the source definition. This is the shape Tares creates, and you can also send the same object with POST /api/sources:

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

4. Tune the optional settings if you need them:
   • limit sets how many rows to fetch per poll.
   • time_column names the timestamp column used for the event time. By default Tares uses the cursor if it is a timestamp, and the ingest time otherwise.
   • text_template sets a one-line summary for each row.
   • The cursor, key and time columns are always included, even when columns lists fewer.
5. Verify. Open the source. Recent events shows rows on the next poll. Fields reports each column’s coverage, so you can confirm the key column is reliably present.

To bring in a JSON API instead, add an HTTP API (poll) source. Set the url, an event_type, and an id_field so items already seen in recent polls are not stored again. Press Discover and Tares calls the API once and fills in the rest. You can also describe the goal to a connected agent or in the AI SRE guided setup.

What you get

• Rows from your own tables sit in the same timeline as the rest of your sources, so an AI SRE can read your application’s data alongside everything else Tares collects.
• Each poll fetches only new and changed rows, driven by the cursor column.
• You choose which columns to pull, and the key column is the one you mark primary.
• Discovery proposes the table, cursor and labels, so you rarely write the source by hand.
• The Fields view shows how reliably each column is present, which tells you whether a label is safe to key on.
• The connection URL stays a secret.
• For API-backed data, the same one-event-per-item model applies: each item in the JSON reply becomes an event, deduplicated by the field you choose.

When something else fits

• Choose the cursor column carefully. A column that does not only grow, or a table with no such column, cannot be read incrementally, so the postgres connector is not the right fit there.
• If the data lives behind an HTTP API rather than in a database you can reach, use the HTTP API (poll) connector.
• If a system should call Tares instead of Tares calling it, the webhook connector is the better path.

Related