Most integration announcements are boring on purpose. A new connector, a checkbox in a settings page, a changelog line nobody reads. This one is boring in exactly that way — until you notice what's actually flowing through the pipe.
Windmill, the open-source internal-tools and workflow-orchestration platform, has shipped a native sync into PostHog's Data Warehouse. Not events. Not usage metrics. Job history, scripts, flows, apps, schedules, resources, users, and audit logs — the actual operational skeleton of whatever you've built on Windmill — now lands as queryable tables inside PostHog, the tool most teams use for product analytics.
That's a strange direction for data to flow. The established pattern in this space is reverse ETL: you pipe cleaned data out of your warehouse and into your SaaS tools (Salesforce, Intercom, ad platforms) via products like Hightouch or Census. Windmill → PostHog runs the other way. An operations tool is pushing its own internals into an analytics product's warehouse, for free, as a first-party feature. Once you sit with that for a minute, it stops looking like a checkbox and starts looking like a bet on where the "warehouse" boundary actually belongs.
What Windmill is, for anyone who hasn't run into it
Windmill came out of Y Combinator's Summer 2022 batch and has since raised from Y Combinator, Gradient Ventures, and Bessemer Venture Partners. The pitch is straightforward if you've ever built internal tools: you write a script — Python, TypeScript, Go, Bash, SQL, Rust, whatever — and Windmill turns it into a scheduled job, a webhook-triggered API endpoint, or a step in a multi-stage DAG workflow, with an auto-generated UI on top if you want one. There's also a low-code app builder for internal dashboards and a full-code builder if you'd rather hand-write the frontend in React or Svelte.
The engine underneath is written in Rust, and Windmill's own benchmarks claim roughly 13x the throughput of Apache Airflow as a self-hosted workflow runner — the kind of number you should treat as a vendor claim until you've run your own load test, but it's consistent with the general pattern of Rust-based job runners outperforming Python-based orchestration frameworks on raw scheduling throughput.
It's self-hostable for free. Windmill Cloud starts around $10/month per "author" seat, with plans reportedly running from roughly $48 to $840/month depending on scale. The company says it's in use at over 4,000 organizations, with 300+ paying enterprise customers including Zoom and Photoroom, and it holds SOC 2 Type II certification — the compliance line every infrastructure vendor now puts in its first paragraph.
If you've used Retool or n8n, Windmill sits in similar territory but leans harder into "real code, real DAGs, self-hostable by default" rather than drag-and-drop automation. It's infrastructure, not a dashboard toy — which is exactly why what it just started exporting is worth paying attention to.
What PostHog's Data Warehouse actually does
PostHog started as product analytics — the open-source alternative to Mixpanel and Amplitude, with the now-familiar "one SDK, own your data" pitch. Its Data Warehouse feature, built on DuckDB, extends that by letting you link external data sources — S3 buckets, GCS, Cloudflare R2, or data fed in by tools like Fivetran, Airbyte, or Stitch — so those tables live alongside your PostHog event data and can be joined against it in the same SQL layer, which itself runs on ClickHouse underneath PostHog's core.
The pitch against Fivetran and Airbyte is cost and integration depth: PostHog doesn't charge extra for the warehouse if you're already a paying customer, the free tier covers up to a million warehouse rows, and because the sync is native rather than a third-party connector, PostHog can offer webhook-based near-real-time updates for supported sources instead of Fivetran's typical batch-sync cadence. Each linked table gets its own sync strategy — full refresh or incremental — chosen per source and per table, not globally.
This is the part that matters for the Windmill story: PostHog wasn't building a generic ETL competitor for its own sake. It was building a landing zone, and it needed sources willing to land there. Windmill just became one of the more operationally sensitive ones.
How the sync actually works
The mechanics are unremarkable on their own, which is part of the point — this isn't some novel streaming architecture, it's a standard connector pattern applied to an unusual dataset. Windmill exposes its internal Postgres-backed state as a linkable source, the same category PostHog already uses for S3 buckets and Fivetran/Airbyte-fed tables. You authorize the link once, at the workspace level, and PostHog's warehouse layer treats each Windmill table — completed_job, flow, script, app, schedule, resource, user, audit_log, and so on — as a separate source with its own sync configuration. Under the hood, PostHog's warehouse queries land on DuckDB, which is built for exactly this kind of federated query over externally-sourced tables sitting next to ClickHouse-native event data, without requiring you to physically co-locate the data in ClickHouse itself.
Per table, PostHog picks one of two strategies:
- Completed jobs sync incrementally — new job runs get appended without re-pulling the whole history, presumably keyed on job ID or completion timestamp.
- Everything else gets a full refresh on each sync cycle — scripts, flows, apps, schedules, resources, users, and audit logs are dropped and re-pulled wholesale rather than diffed.
That asymmetry is worth sitting with. Job history is the one table here that's genuinely append-only and analytics-shaped, so incremental sync is the obvious choice. Audit logs, users, and resource definitions being full-refresh means every sync cycle re-pulls your entire workspace's user list and configuration surface from scratch, rather than diffing it against what's already landed. For a small team running a handful of scripts, that's a non-issue — the tables are small enough that "full refresh" and "incremental" cost roughly the same thing. For one of Windmill's 300+ enterprise customers with a workspace full of scheduled jobs, service accounts, and years of accumulated audit history, full refresh is a meaningfully different cost and latency profile, and it's the kind of detail that shows up three paragraphs into a docs changelog, not in the feature announcement.
There's also a practical consequence for how "fresh" this data actually is. Incremental job-history sync can approach real-time if PostHog's webhook-based sync path applies to it; full-refresh tables are only as current as the last completed sync run, which for a large workspace could be minutes to hours behind, depending on how PostHog schedules the pull. If you're building a dashboard that assumes "who currently has access to this resource" is live, that assumption doesn't hold — you're looking at a snapshot from the last sync, not the current state of Windmill's Postgres.
What actually changed here
Before this, if you wanted Windmill's operational data in a BI tool, you were looking at Windmill's own audit-log UI, a custom export script hitting its API, or routing everything through a generic ETL tool that treats Windmill as just another Postgres-shaped source (if it's supported at all — Windmill isn't a first-class Fivetran or Airbyte connector today). Now it's a native, no-extra-cost link, maintained by PostHog rather than bolted on by a third party.
The bigger shift is conceptual. Analytics warehouses used to be downstream of "real" data — events, transactions, CRM records. Ops-tooling metadata (who ran what job, which credentials a workflow touched, which internal app got deployed) stayed inside the ops tool, visible to platform engineers and nobody else. Piping that straight into the same warehouse that already holds your product usage data collapses a boundary that most security and compliance teams assumed was there by default, not by policy.
It's also a quiet expansion of what "data warehouse" means as a product category. PostHog isn't just competing with Fivetran and Airbyte on moving customer data around anymore — it's positioning itself as the place where tooling metadata lives too, which puts it in adjacent territory to observability platforms and internal audit systems, categories it wasn't previously competing in.
This fits a pattern PostHog has been running for years
PostHog didn't start as a warehouse company. It started as an open-source Mixpanel alternative, then bolted on session replay, feature flags, surveys, experimentation, and a customer-data-platform layer, one product at a time, all sharing the same underlying event store and billing relationship. The strategy has been consistent the whole way: don't compete on being the best point solution, compete on being the one tool that already has your data, so adding the next capability is a checkbox instead of a procurement cycle.
The Data Warehouse feature is the same move applied one layer up the stack. Instead of PostHog being the destination for events you send it, it becomes the destination for tables other tools already own — S3 exports, Fivetran-fed buckets, and now a native, ops-tool-shaped source in Windmill. Read that way, this integration isn't really "PostHog added Windmill support." It's PostHog continuing to test how far "the place your data already lives" can stretch before it stops being product analytics and starts being general-purpose company infrastructure. Windmill is a useful test case precisely because its data — job runs, audit trails, workspace membership — is about as far from "product usage event" as a table can get while still being something a data team would plausibly want to query.
Why developers should actually care
Cost. If you're already paying for both PostHog and Windmill, this connector is free where a Fivetran or Airbyte pipeline moving the same data would cost real money — Fivetran in particular charges by monthly active rows, and audit-log tables get large fast. The catch is PostHog's free tier caps out at a million warehouse rows total, shared across every source you link, so a busy Windmill workspace can eat that budget by itself before you've linked anything else.
Latency. Incremental sync on completed jobs means near-real-time visibility into job outcomes without babysitting a cron-triggered export. Full refresh on everything else means your resource and user tables are only as fresh as the last sync cycle — fine for a dashboard, less fine if you're trying to use this for anything approaching real-time audit alerting.
DX. This is the genuinely good part. If you already write SQL against PostHog for product metrics, you can now join "which internal workflow failed" against "which customers saw an error" in the same query, without maintaining a separate pipeline to make that possible. That's a real, concrete win for teams running Windmill as their internal-tools backbone.
Lock-in. Every native, free, zero-friction integration is also a gravitational pull. The easier PostHog makes it to land your ops data there, the more of your organization's operational truth lives in a system whose retention policies, access controls, and pricing model you don't fully control from the Windmill side. Windmill remains open-source and self-hostable regardless — but the data about Windmill now has a second home, and that second home isn't self-hosted unless you're also self-hosting PostHog.
Security. This is the one the launch framing skips past. "Resources" and "users" syncing into a second product means connection configurations and workspace membership now exist in two systems with two different access-control models. Windmill separates secret values (stored as encrypted variables) from resource definitions (which reference those variables), so this shouldn't mean raw credentials land in PostHog — but resource names, types, and structure are still operational metadata that tells an attacker a lot about your infrastructure if PostHog access is ever compromised. Nothing here is confirmed as a leak of secret values; it's a legitimate widening of your metadata's blast radius, and it's worth an actual review by whoever owns your compliance posture rather than an assumption that "SOC 2 on both ends" settles the question.
There's a data-residency wrinkle too, easy to miss because it's not specific to this feature — it's just what happens when you link any external source into PostHog's warehouse. If your Windmill workspace holds EU user data in its user table, and your PostHog project is on the US cloud region rather than the EU one, that table's full-refresh sync moves that data across the same regional boundary your legal team may have drawn for a reason. PostHog does offer an EU-hosted cloud option specifically for this kind of constraint, but the connector doesn't enforce region-matching for you — it's on whoever flips this on to check that both sides of the pipe are in the region they're supposed to be in, and that's exactly the kind of one-time config check that's easy to skip during an "ooh, free integration" trial run.
Where this is actually useful
A few concrete scenarios where this connector earns its keep:
- Correlating ops incidents with product impact. Join Windmill's job-failure history against PostHog's error and session data to answer "did that failed nightly sync actually affect users" without stitching two dashboards by hand.
- Internal-tools usage reporting. If your internal apps are built in Windmill, you can now report on who's using which internal tool, how often, alongside your actual product usage — useful for platform teams trying to justify headcount or sunset unused tooling.
- Lightweight audit reporting for smaller teams. Teams too small to run a dedicated SIEM can get basic "who ran what, when" visibility for free, inside a tool they're already paying for, instead of standing up a separate log pipeline.
-
Reliability trend lines. Because
completed_jobsyncs incrementally and cheaply, it's realistic to build an ongoing view of job success/failure rates per flow over time — something that's normally a Grafana dashboard bolted onto a metrics exporter, now achievable with a query against a table that already exists.
A rough shape of what that last query looks like once both sources are linked in the same PostHog project — joining Windmill's job outcomes against product error events by rollout window (column and table names below are illustrative; PostHog hasn't published the exact synced schema at the time of writing, so check the linked source's schema browser in your own workspace before copying this):
select
j.script_path,
date_trunc('day', j.created_at) as day,
count(*) filter (where j.success = false) as failed_jobs,
count(distinct e.distinct_id) as affected_users
from windmill.completed_job j
left join events e
on e.timestamp between j.created_at and j.created_at + interval '1 hour'
and e.event = '$exception'
where j.created_at > now() - interval '30 days'
group by 1, 2
order by failed_jobs desc;
That's the entire pitch for this integration in one query: a join that used to require exporting two datasets into a third tool now runs against tables that are already sitting in the same warehouse.
Where it's a worse fit: anything that actually needs to be a compliance-grade audit trail. Full-refresh syncs, a shared free-tier row cap, and a general-purpose analytics UI are not a substitute for an immutable, purpose-built audit log with its own retention guarantees. If a regulator or auditor is going to ask for that data, this connector is a convenience layer on top of Windmill's real audit system, not a replacement for it.
What the marketing doesn't say
Release notes call this a data warehouse sync. What they don't spell out: it's an asymmetric one (incremental for the cheap table, full refresh for everything expensive to re-pull), it competes for the same free-tier row budget as every other source you link, and it's currently a one-way pipe — Windmill's data lands in PostHog, but there's no managed path for PostHog insights to flow back into a Windmill flow without you writing that integration yourself using Windmill's existing HTTP/webhook capabilities. That's not a flaw, exactly — Windmill was already perfectly capable of calling PostHog's API from a script before this integration existed — but "PostHog integration" implies more bidirectionality than what actually shipped.
The other thing worth naming: this is a two-vendor dependency for a workflow that used to be single-vendor. If PostHog's sync breaks, or Windmill changes its internal schema, your ops-visibility dashboard breaks with it — and debugging that now spans two products' support queues instead of one.
How this stacks up against the alternatives
Compared to routing Windmill's data through Fivetran or Airbyte into a general-purpose warehouse like Snowflake or BigQuery: you get more flexibility and a more mature audit/retention story with a dedicated warehouse, at real per-row cost and real setup time, and neither Fivetran nor Airbyte has a first-class Windmill connector today, so you'd likely be building a custom one regardless.
Compared to Retool's or n8n's own audit-logging: both keep that data inside their own product, which is more contained but means you're back to stitching dashboards by hand if you want it alongside product analytics.
Compared to a dedicated observability platform ingesting Windmill's logs: you'd get proper log-search, alerting, and retention tooling built for exactly this job — at the cost of running (and paying for) a separate system. PostHog's warehouse is not trying to be that, and shouldn't be evaluated as if it were.
The honest framing is that this connector isn't competing head-on with any of those. It's competing with "nothing," for the large number of Windmill users who currently have zero cross-tool visibility into their ops data because setting up any of the above felt like too much work for a mid-sized team. For that audience, free and native beats mature and expensive, and that's most of why this is worth writing about at all.
It's also worth naming what this isn't a competitor to: a customer data platform like Segment. Segment's job is routing well-modeled customer events to dozens of downstream destinations; PostHog's warehouse is the opposite motion, pulling arbitrary external tables in. They solve adjacent but distinct problems, and the fact that PostHog's own product already absorbed a lot of what a lightweight CDP does is a separate, older story — this integration doesn't change that comparison, it just adds one more source type PostHog can ingest.
Setting it up, if you're going to
The actual mechanics of turning this on are unremarkable enough that they don't need a walkthrough: link Windmill as a source from PostHog's Data Warehouse settings, authorize it against your Windmill workspace, and pick sync frequency per table. The part worth doing deliberately, rather than accepting defaults, is deciding which tables you actually link. PostHog's per-table sync configuration means you're not forced to take an all-or-nothing import — a team that wants job-outcome analytics without importing the full user and audit-log tables can link completed_job and flow alone and skip the rest, which sidesteps most of the compliance and row-budget concerns raised above while still getting the actual DX win this integration is for.
Who should try it, who should wait
If you're already running both Windmill and PostHog, and your Windmill workspace is small enough that a full-refresh sync of users, resources, and audit logs won't blow past PostHog's free row cap, turn this on — it's a genuine, low-effort DX win with no new infrastructure to run.
If you're a larger Windmill deployment with real compliance obligations around who can see workspace membership and resource configuration, hold off until you've had someone with actual security ownership look at exactly what "resources" and "users" contain in your instance, and confirm PostHog's access controls and data-retention policy meet whatever bar your audit trail is held to. The features here are additive and reversible — nothing about turning this on is destructive — but "reversible" and "worth reviewing first" aren't the same thing when audit-relevant data is involved.
If you're not running Windmill, this isn't a reason to start — it's a reason to notice the pattern. Watch whether other ops and infra tools follow with their own native PostHog links. If they do, PostHog's Data Warehouse quietly becomes the default landing zone for a much wider slice of company data than "product analytics" ever implied, and that's worth having an opinion on before it becomes the default rather than after.
What's your team's actual policy on ops-tool audit data landing in a second SaaS product — is that a real reviewed decision, or did it just happen because a connector existed and someone clicked "enable"?
Sources:
Top comments (0)