rubenfiszel

It's very close to the direction we're taking for windmill.dev, we call it "operator builders" rather than focus on "knowledge graph" which the article is very light on details of.

What I'm mostly reading is a developer platform and runtime where users can build agents that can run tools and for that you need a secure code runtime, ACL/permissions, easy way to build apps or what cloudflare OS call gadgets. We're betting on this too at https://github.com/windmill-labs/windmill, very curious to see if that's the future for most enterprise and if a model where everyone vibe-code/fork cloudflare OS to their enterprise need is the future, or a more exhaustive/enterprise platform like ours does.

We have over 400+ enterprise customers yet handle all the support with a few engineers. We use Windmill obviously for orchestration but it would work with any orchestrator.

We have bet early on DuckDB and Ducklake for Windmill and couldn't be happier. The focus on server/client mode is interesting, it opens the way for orchestrators like ours to have "lite" workers/jobs for duckdb that connect to one central bigger beefy nodes and improve the overall efficieny. I'm very curious if benchmark shows that there are performance benefits to do so thanks to co-location and overall less cpu cycles wastes.

Would be very cool if as a result the different components were published as crates and embeddable in other rust projects!

workflows is just short for state machine DSL

For the AI workflows, we (windmill.dev) added AI Agent steps as first class primitives very recently.

Windmill.dev (YC S22) | Software Engineers | Paris (ONSITE 3d/wk) | Full-time

Fastest open-source workflow engine built in Rust + Svelte. 300+ Enterprise customers. Profitable with a lean team of 9 engineers.

Looking for new cracked software engineers to join us in Paris.

https://www.ycombinator.com/companies/windmill/jobs

Founder of windmill.

I'm not ashamed to admit than n8n feels more polished. There are a few reasons:

- Our team was and is still much smaller. We were 5 for the first 2 years, we are now 10 (year 3), and are continuing to hire to follow our growth.

- They have been around for longer and mature for longer, more time to iterate. We have reached some level of maturity recently and are now spending more iterations on polishing rather than new features.

- Their surface area is smaller, windmill does A LOT and expose more for the better or worse.

n8n has done a lot of things really well and although we have a different audience, there is a lot to learn from what they did very well and we have the upmost respect for them. We have some overlap, but I think ultimately we strive in different kind of orgs and will cohabit rather than compete.

> That said, we tried Windmill first and while it was cool for the devs who were able to see the vision, the non-technical users hated it

Founder of Windmill here. This is not too surprising although we are working on it by leveraging AI and just better DX/design. Pleasing devs in the most demanding orgs and the ever-changing expectations is challenging by itself. Pleasing both devs AND non-technical user is a monumental task that we are now giving more attention to by focusing on 2 aspects:

- A better DX/UX that does not sacrifice power-user capabilities but has a less step learning-curve and more intuitiveness to it. That is mostly about good design and hard work. We are taking inspiration from the best and on the intuitiveness, we've learned a lot from n8n and other leaders in the space.

- leveraging AI capabilities in a state-of-the-art way to have the best models generate the code for non-technical users. That is basically just adopting the best practices inspired by cursor such as great auto-completion, great inline code-gen, excellent semantic search.

But the videos show claude web

I feel dumb but how do you actually add Zapier or Confluence or custom MCP on the web version of claude? I only see it for Drive/Gmail/Github. Is it zoned/slow release?

You should give a try to Windmill, it's more of a workflow engine than a data orchestration tool but it's intuitive and open-source.

We are customers at windmill.dev and we are really happy with it. It also motivates us to write ever better docs as it means more answers can be an answered completely by the bot.

Ola from windmill.dev, another open-source VC-backed company using AGPL. We actually spoke before your pivot and we now have a bit overlap on the dashboard builder but our audience is fairly separate.

Congrats, you made what I believe is the best move a software company can do in our space. You will hear a lot of naysayers, and sure the software we build is not as permissive as Apache 2.0 and MIT. Those are all true and valid points. It's also true that VCs have perverse incentives and as a naturally skeptic myself, I understand not wanting to touch it.

Let me bring a little bit of counter-points to those:

- AGPL or Commercial Open-Source Software would probably just not exist at all if there was no path to commercialization at all. So the dichotomy between making it true MIT or AGPL is a false one, it's the choice between proprietary/no software and AGPL and I think we can all agree the latter is better. Software Engineers need to eat and there is a pool of talented engineers for whom glory is not fully sufficient and also need their work to be a reasonable financial paths. This enables more SWE to compete to build more software and make the software landscape more competitive for the benefit of the end-users.

- Taking VC money is not signing a pact with the devil that strips away your entire freedom, especially at @lucasfcosta stage and ours. The real issue is with being fully dependent on that money by having bad financial health and needing to raise in X months. COSS company like ours can stay lean and profitable, taking just the right amount of money from VC to kickstart a long-term journey to become a behemoth of a software company through having advantages over all the proprietary alternatives. Windmill for instance is profitable, and no investors has ever pressured us to go faster or monetize more. 99% of our users are using the free/open-source version but the 1% that is not is made of medium and large enterprises that hugely appreciate running their infra on open-source software that they can easily audit and contribute to. It would have been SO MUCH harder to convince them without being open-source given our size. Another fact that helps is pricing but that is also related to our open-source nature. It's harder to over-price your large customers because at a certain point they can say screw it, they will just build in-house to go above the proprietary features. All that to say that companies do have incentives but also are made of humans which have their own values and goals, and have some agenda to set their own path, especially early on. It's all about balance and I would argue taking a bit of VC money at the seed-stage at a good valuation and then not much more is the optimal path right now.

If you can make it work with Rust, and compatible with wasm targets as well, it opens a huge field of possibilities.

Windmill.dev is a workflow engine based fully on postgresql. This would be the missing piece to offer a local development workflow that doesn't require spinning a full pg.

This is super timely.

Windmill (https://windmill.dev) used to only support webhooks to trigger code and flow jobs. We have just added email support building our own MX server, and wanted to add CDC change. We were gonna do it on Debezium but this will allow us to remove the need for a third-party service and just add this as a crate. Thank you supabase for open-sourcing this.

At windmill.dev, when users deploy their code, we use Bun build (which is similar to esbuild) to bundle their scripts and all their dependencies into a single js file to load which improve cold start and memory usage. We store the bundle on s3 because of the size of the bundles.

If we could bundle everything to native that would completely change the game since as good as bun's cold start is, you can't beat running straight native with a small binary.

Founder of https://windmill.dev here which share many similarities with Maestro.

> Maestro is a general-purpose, horizontally scalable workflow orchestrator designed to manage large-scale workflows such as data pipelines and machine learning model training pipelines. It oversees the entire lifecycle of a workflow, from start to finish, including retries, queuing, task distribution to compute engines, etc.. Users can package their business logic in various formats such as Docker images, notebooks, bash script, SQL, Python, and more. Unlike traditional workflow orchestrators that only support Directed Acyclic Graphs (DAGs), Maestro supports both acyclic and cyclic workflows and also includes multiple reusable patterns, including foreach loops, subworkflow, and conditional branch, etc.

You could replace Maestro with Windmill here and it would be precisely correct. Their rollup is what we call the openflow state.

Main differences I see:

- Windmill is written in Rust instead of Java.

- Maestro relies on CockroachDB for state and us Postgresql for everything (state but also queue). I can see why they would use CockroachDB, we had to rollout our own sharding algorithms to make Windmill horizontally scale on our very large scale customer instances

- Maestro is Apache 2.0 vs Windmill AGPL which is less friendly

- It's backed by Netflix so infinite money but although we are profitable, we are a much smaller company

- Maestro doesn't have extensive docs about self-hosting on k8s or docker-compose and either there is no UI to build stuff, or the UI is not yet well surfaced in their documentation

But overall, pretty cool stuff to open-source, will keep an eye on it and benchmark it asap

Why not call it pg_duckdb ?

It wouldn't even be that hard since we have our own layer on top of monaco to resolve types that could dynamically fetch it from Twenty.

Yes, we(Windmill)'d be a kick-ass combo. We're users of twenty ourselves. As both open-source projects, a third option that I'm often recommending is having such great integration in both products such that their users can independently chose to use and install Windmill (self-host or cloud) and have it power all of the orchestration and arbitrary-code needs of the third service without the need for a formal whitelabel.

1/3 of Parisians are born there, 1/3 are born in France, 1/3 outside of France: https://www.paris.fr/pages/seulement-30-des-parisiens-sont-n...

I'm surprised, and so my statement above is wrong as more people in Paris are born outside of it, I would have thought it was more than 50%

Paris is mostly inhabited by parisians, born there, where do you think we all go once we come of age?

You might have came in Summer/August, where all the parisians disappear because there are too many tourists and it's too hot so if you can afford it you go to the south of France/abroad.

Also the experience you will have as a tourist is indeed of a museum, the experience you will have living here inside french circles is vastly different but, like in every city, it's not something that you can create in 1 week or 2. I would even say, if you're not french or parisian, you will have difficulties joining the right inner circles. It's not a good thing, it's not something to be proud of, but the parisian life is extremely lively. It's exactly the same than in New York, there are more to scratch than the surface but it's not something that you can "consume" easily just because you have a wallet.

I think it finally occurred to me that you care only to transform data insofar as it is for the purpose of being used in BI/dashboards and not for data warehouse purposes. That wasn't clear to me at first but it makes sense.

From an external look, that sounds a lot like what dbt is meant to be. Why would one choose quary over dbt?

We use this for generation: https://hub.windmill.dev/scripts/helper/1508/generate-a-lice... and this for client-side checking (https://hub.windmill.dev/scripts/helper/1510/verify-a-licens...) actually the real one is in rust but same algorithm.

Inngest is very cool, and if you are interested in the topic but absolutely want to self-host, 2 other high-performance durable execution engines that enable all the above and that you can self-host and are open-source and mature would be temporal and windmill. Both can use postgresql as the queue (temporal can use cassandra too), the rest can be done leveraging the transactional properties of postgresql, such as atomic counters for the concurrency keys: https://github.com/windmill-labs/windmill/blob/main/backend/... or re-queuing jobs that haven't progressed when they should have (most likely, worker crashed).

There are very cool things you can do today without too much complexity with the primitives that modern database are capable of. Should one rebuild it for their startups, no, but if you were to extract the very core of the durable execution engine of windmill for instance, it would actually be surprisingly reasonable given that postgresql does the heavy lifting. I strongly believe the benefits of our platforms mostly come from the overall virtue to be standardized, opinionated and working out-of-the-box in a way that make everything fit together rather than the overall engineering complexity of it.

Windmill is used by large enterprises to run critical jobs that require a predefined amount of resources and can run for months if needed, stream their logs, written in code at scale with upmost reliability, throughput and lowest overhead. The only insight from Zapier is how easy it is to develop new workflows.

I understand our positioning is not clear on our landing (and we are working on it), but my read of hatched is that what they put forward is mostly a durable execution engine for arbitrary code in python/typescript on a fleet of managed workers, which is exactly what Windmill is. We are profitable and probably wouldn't if we were MIT licensed with no enterprise features.

From reading their documentation, the implementation is extremely similar, you define workflows as code ahead of time, and then the engine make sure to have them progress reliably on your fleet of workers (one of our customer has 600 workers deployed on edge environments). There are a few minor differences, we implement the workers as generic rust binary that pull the workflows, so you never have to redeploy them to test and deploy new workflows, whereas they have developed SDK for each languages to allow you to define your own deployable workers (which is more similar to Inngest/Temporal). Also we use polling and REST instead of gRPC for communications between workers and servers.

Ola, fellow YC founders. Surely you have seen Windmill since you refer to it in the comments below. It looks like Hatchet, being a lot more recent, has currently a subset of what Windmill offers, albeit with a focus solely on the task queue and without the self-hosted enterprise focus. So it looks more like a competitor to Inngest than of Windmill. We released workflows as code last week which was the primary differentiator with other workflow engines and us so far: https://www.windmill.dev/docs/core_concepts/workflows_as_cod...

The license is more permissive than ours MIT vs AGPLv3, and you're using Go vs Rust for us, but other than that the architecture looks extremely similar, also based mostly on Postgres with the same insights than us: it's sufficient. I'm curious where do you see the main differentiator long-term.

Windmill is is built exactly like that, what box is left unchecked for it if you had time to review it?