What is pgpulse?

PgPulse is a backend service that tracks how well the API endpoints of an application are performing: how much traffic they get, how many requests fail, and how slow they are. It is described as similar in spirit to Datadog, New Relic, or Stripe's dashboards, but scoped specifically to API request analytics, and built to serve many separate customers at once with each one's data kept fully isolated using PostgreSQL's row level security. It does not watch traffic on its own. Instead, a backend application reports each request to PgPulse over an HTTP call, for example noting that a checkout endpoint returned a success status in 42 milliseconds. PgPulse stores these events and then answers questions about them, such as total request counts, error rates, the slowest endpoints, and latency percentiles over time. Each customer using PgPulse is called a tenant and gets an API key. That key both authenticates the reporting calls and scopes every analytics query to that tenant's own data. Reporting traffic (writes) goes to the primary database, while analytics queries (reads) are served from a separate read replica, so a heavy analytics dashboard never slows down the ingestion of new events. There is no built in user interface. Everything happens over HTTP, so a team would build their own dashboard or script on top of it, or use the included curl examples directly. Using it in an existing app takes three steps: create a tenant to get an API key, add a small piece of code to the backend that reports each request after it finishes (with a batch endpoint available for high traffic setups), and then query the analytics endpoints for insight whenever needed. The README is explicit that the API key is a server side secret and should never be placed in browser code. Under the hood it is built with Node.js, the Fastify web framework, and TypeScript, backed by PostgreSQL 16 using partitioned tables, various index types, and a materialized view refreshed on a schedule by pg_cron. Connection pooling is handled by PgBouncer, and alerting is done with in-database threshold checks that deliver webhooks rather than a separate message queue. The project ships with a Docker Compose setup that starts the primary database, a replica, PgBouncer, a migration step, and the app itself, along with a health endpoint reporting pool and replication status.