Beton + Postgres

Why Postgres is a first-class data source for Beton

Many of the companies Beton works with don't keep their primary product data in PostHog at all — they keep it in their application database, often Postgres, and have a separate analytics tool that's a copy of a copy. For these teams, the most authentic signal source is the database that the product itself reads and writes against. Logins, feature usage, transactions, subscription state changes — they're all already there, with the schema discipline that production databases enforce and the query semantics that warehouse layers usually flatten.

Beton connects to your Postgres warehouse (or a read replica) using a standard read-only connection string. The agent inspects your schema, identifies the tables that look like event streams or activity logs, and proposes hypotheses against the rows that already exist. You don't need to instrument anything; you don't need to run a separate ETL; the signals flow straight from the source of truth.

Common patterns in warehouse-style Postgres data

• Subscription state transitions — trial-to-paid, plan upgrades, downgrades, cancellations. The state-change rows are usually the highest-signal events in the database, and they're often the first table Beton flags as a hypothesis source.
• API usage tables — request logs, rate-limit hits, error responses. For products with API surface, these tables capture the customer's actual usage trajectory in a way that no marketing dashboard does.
• Per-user activity tables — login_events, action_logs, audit_trails. The granularity here is usually sufficient to detect activation depth, return cadence, and feature breadth without needing PostHog overlay.
• Billing and invoicing tables — invoice_line_items, usage_meters, plan_history. Especially important for usage-based pricing models where the billing event is the buying signal.
• Relational signals — joins between users, accounts, and feature usage that PostHog can't naturally express. Postgres lets the agent ask "which accounts have at least three users who hit feature X" as a single query, which is awkward to express in event-stream terms.

Read-only and rate-aware

Beton's Postgres connector uses a read-only role and respects connection-pool limits. Sync runs as scheduled batched queries against the tables Beton has been authorized to read, not as a continuous stream against your live database. For teams that worry about analytical load on production, the pattern we recommend is connecting Beton to a read replica or a follower database — the same way most BI tools do — so production OLTP performance is unaffected.

When Postgres is the better choice over PostHog

Three cases come up regularly. First, when the product was built before product analytics tooling was standard, and the database has years of behavioral history that PostHog doesn't. Second, when subscription state and billing events live in the application DB but not in PostHog, and the most useful expansion signals are state-change rows rather than user actions. Third, when the team has compliance constraints that prevent product event data from leaving the application boundary — Beton's Postgres connector lets the analysis happen against the source database without copying anything to a third-party analytics platform.

Connection takes minutes. Beton supports the standard connection pool patterns, schema introspection runs on first connect, and hypothesis backtesting starts as soon as the agent has a converter cohort to compare against. From there, the same pipeline that handles PostHog signals applies to Postgres-derived ones — proposed hypothesis, backtest, approve, route to your CRM.