Last updated: September 16, 2026

Privacy Policy

pgfence is built to minimize data collection. The website is public, the analyzer runs locally on your files, and any Cloud design-partner work is handled through direct conversations rather than self-serve accounts on this site. From version 0.8.0 the CLI also sends anonymous usage counts, which carry no SQL and no file names, and which you can turn off.

What we collect

  • Messages you send to us through contact, email, or sales inquiries.
  • Basic server logs needed to operate the website.
  • If first-party funnel analytics are configured, page-view and explicitly tagged CTA-click events on the pricing, cloud, and contact pages, plus the tracking fields that actually ship in the payload.
  • Information you intentionally share during direct Cloud design-partner evaluation, onboarding, or support.
  • Anonymous per-run usage counts from the pgfence CLI, version 0.8.0 and later, unless you opt out. The telemetry page lists every field.

What we do not collect

  • Production database credentials for the standard cloud workflow.
  • Migration contents from the CLI unless you explicitly upload or share them. CLI telemetry is not an exception: it never carries SQL text, file names, or paths.
  • Third-party ad pixels, cross-site trackers, or cookie-based marketing profiling on this site, as of this release.
  • A self-serve account profile, login identity, or authenticated cloud workspace on this public website today.

CLI telemetry

pgfence 0.8.0 and later send anonymous usage counts from the CLI, so we can tell how many people run it and how. On an interactive terminal, the first run on a machine prints a notice explaining this and records and sends nothing at all; collection starts on the run after the notice has been shown. CI is the exception and is worth stating plainly: a CI run sends on its first run without printing a notice, because there is no terminal to print it to and a build log is not a disclosure. The complete field list, a real payload, and the state file locations are on the telemetry page.

Each event is a fixed set of 25 fields describing one run: mostly counts and values from closed lists, plus two random identifiers, a duration, and a timestamp. Among them are the command, the pgfence version, the Node major version as an integer, the operating system as a platform name from a fixed list rather than a version string, whether the run was in CI and on which provider, the detected migration format, a bucketed file count, how long the run took, and counts of findings by severity plus policy errors and warnings. Events go to telemetry.pgfence.com, which we operate. The receiver stores no IP address, no geography, and no user agent, and rows are deleted 400 days after they arrive.

installId is a random 128-bit value generated on your machine on first run and stored in your user config directory. It is not derived from your hardware, user name, network, or any account, but it is stable across runs on that machine, so treat it as pseudonymous rather than strictly anonymous. CI runs never write to disk. On an ephemeral runner, where no id exists, the run mints one, uses it once and discards it. On a self-hosted runner or any image with a persistent home directory, an id that is already there is read and reused, so it stays stable across builds. pgfence telemetry status prints yours, and pgfence telemetry reset deletes it.

Never sent, by construction: SQL text in any form (including fragments, previews, and hashes), file names, paths, or directory names, table, column, index, and schema names, rule ids and messages, anything read from a database through --db-url or a stats file, git remote, branch, or commit, your working directory, hostname, user name, environment variable values, and any free-form string.

Any one of these turns it off:

  • PGFENCE_TELEMETRY=0 in the environment.
  • DO_NOT_TRACK=1 in the environment.
  • pgfence telemetry disable, which also deletes anything still queued.
  • telemetry = false in the project's .pgfence.toml or .pgfence.json.

The environment and project-file opt outs are resolved before any state file is read or created, so a machine opted out that way never generates an install id during an analysis run. The language server (pgfence-lsp) sends nothing in any configuration.

Third-party services

This site serves its fonts locally and links out to GitHub, npm, and the VS Code Marketplace. Those destinations have their own privacy practices.

Website funnel analytics

This section covers the website only, and is separate from CLI telemetry above. When configured, website measurement is first-party and intentionally narrow. We only track page views and explicitly tagged CTA clicks on the pricing, cloud, and contact pages. Each event can include event, site, page_path, page_title, referrer, utm_source, utm_medium, utm_campaign, utm_content, and utm_term. CTA clicks can also include cta_id, cta_location, and cta_destination. We do not use cookies or local storage for that flow, and the tracking code respects browser Do Not Track and Global Privacy Control signals.

Accounts and cloud access

The public website does not currently provide signup, sign-in, or account management. If pgfence Cloud is discussed during a design-partner evaluation, any data sharing or onboarding happens through direct communication and separate agreement, not through a public self-serve app on this site.

Retention and access

If you need a data deletion request or want to review what we have on file, contact us at [email protected].

Telemetry rows are deleted 400 days after they arrive. If you want yours deleted sooner, run pgfence telemetry status and send us the install id it prints. That id is the only handle we have on events from your machine, so we cannot find them from your name, email, or IP address.