Deliver product events to customer data warehouses
Your customers' data teams want events in the warehouse they already use. Pushrail streams them there directly, BigQuery, Snowflake, ClickHouse, or anywhere SQL-shaped.
The problem
Data teams have a clear preference: they want product event data inside the warehouse where everything else already lives. That's where the dashboards are, where the joins make sense, and where the compute is already paid for. Sending them CSVs, webhooks they have to consume, or files they have to load is friction that delays the work they actually care about.
For SaaS vendors, this creates a recurring engineering ask. Each warehouse vendor has its own quirks: BigQuery prefers Storage Writes, Snowflake prefers continuous loads from a stage, ClickHouse prefers large batches with deterministic inserts. Building one warehouse adapter is a quarter of engineering time; building several is a roadmap derail.
The result is usually a half-built warehouse integration that targets one platform and breaks on the others, leaving customers with the wrong warehouse out in the cold.
How Pushrail solves it
Pushrail ships native adapters for the three warehouses customers ask for most: BigQuery, Snowflake, and ClickHouse. Each adapter uses the warehouse's preferred ingest path, Storage Writes for BigQuery, Snowpipe-style staging for Snowflake, batched native-protocol INSERTs for ClickHouse, so latency and throughput match what the customer's data team expects.
The canonical event shape is the same across all three: an `event_id` UUID, `event_type` string, `occurred_at` timestamp, `customer_external_id`, `source`, and JSON `payload` / `metadata` columns. Customers with multiple warehouses see consistent tables; customers with one don't care.
Idempotency is built in. Pushrail's adapter dedupes by `idempotencyKey + eventType`, so replays, whether triggered by an operator or by the customer fixing their own broken credentials, never inflate row counts.
What you ship to your customers
- Direct event delivery into the customer's BigQuery, Snowflake, or ClickHouse, billed to their warehouse account.
- Table-per-event-type or single-table mode, picked by the customer based on how their analysts work.
- Schema-aware columns plus a JSON payload column for forward-compatible event evolution.
- Per-delivery audit trail visible to your customer's data team, no more 'is the data flowing?' tickets.
- Replay any time window into the same warehouse, idempotent, no duplicates.
What this replaces
- A backlog of 'we want our data in BigQuery' enterprise customer requests.
- A custom in-house adapter for each warehouse vendor.
- Reverse-ETL or CDP intermediaries that add a hop, a vendor, and a bill.
- Maintenance of file-based exports that data teams have to load themselves.
Concrete walkthrough
- 1. The customer's data team creates a dedicated service account in their warehouse with INSERT on the target dataset/schema/database.
- 2. They grant Pushrail access, Workload Identity Federation for BigQuery, key-pair auth for Snowflake, password for ClickHouse.
- 3. They configure the destination in your dashboard: pick a warehouse, paste the credentials, choose table-per-event-type or single-table.
- 4. Pushrail starts streaming. The first row appears in seconds.
- 5. Their analysts query the new table from Looker, Mode, dbt, or whatever else they already use.
Destinations this uses
Stream events directly into a customer's BigQuery dataset, table per event type or single wide table.
Continuous ingest into a customer-owned Snowflake table via Snowpipe-style staging.
High-throughput row-shaped event delivery into a customer's ClickHouse cluster, one row per event.
Deliver events as NDJSON files into a customer-owned S3 bucket, batched, partitioned, and idempotent.
Related use cases
Stop building one-off CSV exports, let customers stream events into their own warehouse, lake, or queue.
Let enterprise customers point your events at their own infrastructure, close the ACV-driving deals without bespoke engineering.
Drop an embedded portal into your app where customers configure their own destinations, without building the portal yourself.
Frequently asked questions
Which warehouses does Pushrail deliver to?
BigQuery, Snowflake, and ClickHouse, the three customers ask for most. Each adapter uses the warehouse's preferred ingest path: Storage Writes for BigQuery, Snowpipe-style staging for Snowflake, and batched native-protocol INSERTs for ClickHouse.
Do I have to build a separate adapter for each warehouse?
No. You send one canonical event to Pushrail's ingest API and the matching adapter handles each warehouse's quirks. The event shape, event_id, event_type, occurred_at, customer_external_id, source, and JSON payload/metadata, is consistent across all three.
Who pays for the warehouse compute?
The customer. Delivery lands in their BigQuery, Snowflake, or ClickHouse account, so ingest and query compute is billed to them, not to you.
Are replays safe against the warehouse?
Yes. Pushrail dedupes by idempotency key plus event type, so replays, whether triggered by an operator or by the customer fixing their own credentials, never inflate row counts. Customers can replay any time window into the same warehouse.
Deliver product events to customer data warehouses
Sandbox is open. No credit card.