flow VS windmill

We use a macaddr8 that embeds a wall-clock timestamp (so they're ascending order, achieving data locality) with some additional randomness. It's worked really well for us:

https://github.com/estuary/flow/blob/master/supabase/migrati...

we use macaddr8 instead of bigint, because it has a postgres serialization / JSON encoding which lossless-ly round-trips with browsers and it works well with PostgREST. The same CANNOT be said for bigint, which is a huge footgun.

I can't claim to know much about CloudQuery, but we are an open-source platform with CDC connectors from PostgreSQL and materializations to BQ and elsewhere. We also have fully-managed connectors if you don't want to deal with hosting.

This is essentially how we model things in Flow (disclosure: I work there). We call them Derivations, which are data products that are built (derived) from other data products. Each data product (we call them Collections) is backed by a set of append-only logs, so they can be read by many different consumers at different times. IDK if our product can work for you since we don't (yet) support stuff like MQTT, but there's a pretty generous free tier if you'd be able to push the data over HTTP. Either way, I just think it's cool that others have independently arrived at similar ideas about how to model streaming tasks!

We Estuary Git Docs have an open-source connector for Kafka -> Snowflake that could perform the tasks of a) flattening the data and b) removing duplicates via exactly once end to end delivery

Estuary Technology | Backend Engineer | Developer Evangelist | Rust, Go | REMOTE OR HYBRID | UTC-7 to UTC+2

Regional offices in NYC & Columbus, OH

Estuary (https://www.estuary.dev/) is the first real-time Data Operations platform for future-proof pipelines, including both historical and real-time data set up in minutes.

Our team is rapidly growing, VC funded and led by two successful, repeat founders.

We primarily develop in Rust and Go and are heavily built on top of gazette which is an internally developed streaming engine.

Flow: https://github.com/estuary/flow

Gazette: https://gazette.readthedocs.io/en/latest/

Backend Engineer: https://www.estuary.dev/about/#backend

Developer Evangelist: https://www.estuary.dev/about/#developerevangelist

^This is an exciting opportunity to make direct impact and shape user perception of a new product that brings a fresh experience to working with real-time data.

As this is a unique role, we are open to a variety of personas (data engineers, backend developers, Solutions Engineers and of course DevRel professionals).

Estuary offers full health benefits, competitive salary, unlimited PTO, 401K, equity, and a culture that values trust, transparency, and a flexible work environment to optimize your work/life balance.

To apply, send your resume and any questions to [email protected]

Flow Gazette We are looking for a backend engineer who is early in their career (around 1-3 years of industry experience) to join our team.

Estuary Technology | Junior Backend Engineer | Rust, Go | REMOTE OR HYBRID | Regional offices in NYC & Columbus, OH

Estuary (https://www.estuary.dev/) is the first real-time Data Operations platform for future-poof pipelines, including both historical and real-time data set up in minutes.

Our team is rapidly growing, VC funded and led by two successful, repeat founders.

We primarily develop in rust and go and are heavily built on top of gazette which is an internally developed streaming engine.

Flow: https://github.com/estuary/flow

Gazette: https://gazette.readthedocs.io/en/latest/

We are looking for a junior backend engineer with 2-3 years of industry experience.

For engineers who have an unquenched curiosity and drive to solve complex distributed systems problems, this is an opportunity to advance your career alongside a team of subject matter experts.

We are focused on expanding our catalog of open-source data connectors and building out our managed service platform.

ESTIMATED COMPENSATION: $110,000 - $150,000.

Estuary offers full health benefits, competitive salary, unlimited PTO, 401K, equity, and a culture that values trust, transparency, and a flexible work environment to optimize your work/life balance.

Email your resume to [email protected] to apply!

It does seem like a weird bug that this would cause errors https://github.com/estuary/flow/runs/5642694619?check_suite_... seems like it should be some kind of warning instead of an error?

where you'd subscribe for live updates.

[1]: https://github.com/estuary/flow

Data Handling: Utilizes Windmill for data pipelines, with a primary database powered by PostgreSQL. Auxiliary data storage is handled by MongoDB, with Redis for caching to optimize performance

Look very similar to the script builder portion of https://github.com/windmill-labs/windmill, but not open-source, not self-hostable, and without open-source integrations (https://hub.windmill.dev/)

disclaimer: I'm founder of ^

If you need a job queue on Postgres, https://windmill.dev provide an all-integrated developer platform with a Pg queue at its core that support jobs defined in python/typescript/sql

windmill.dev - Windmill is an open-source developer platform to quickly build production-grade multi-step automation and internal apps from minimal Python and Typescript scripts. As a free user, you can create and be a member of at most three non-premium workspaces.

For an alternative to airplane.dev, you can checkout Windmill.

https://github.com/windmill-labs/windmill

"Open-source developer infrastructure for internal tools (APIs, background jobs, workflows and UIs). Self-hostable alternative to Airplane, Pipedream, Superblocks and a simplified Temporal with autogenerated UIsm and custom UIs to trigger workflows and scripts as internal apps.

Scripts are turned into sharable UIs automatically, and can be composed together into flows or used into richer apps built with low-code. Supported script languages supported are: Python, TypeScript, Go, Bash, SQL, and GraphQL. "

If you search HN, you'll find the creator of Windmill comment on comparisons to airplane.dev:

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

https://windmill.dev is a self-hostable OSS alternative to pipedream

(disclaimer: I'm founder)

I'm genuinely curious what server-side stuff on BC you are referring to. That may have been something added after our assessment. The way I'd generally approach something like that for any of the platforms would be using an external low/no code solution to process webhook data. But it would depend heavily on the use case. For a more developer friendly option I've been really impressed by windmill.dev. We use a mix of n8n and windmill for various needs.

Yes it goes in that direction, however note that you can already do this in a not too hard way.

Our openflow spec is both open-source and has a full openapi definition: https://github.com/windmill-labs/windmill/blob/main/openflow...

you can use that to generate client sdks in any languages and build your own dag with it. That's what one of our customer did building a reactflow to openflow library: https://github.com/Devessier/reactflow-to-windmill

It's not as good as the decorator way but we move fast and if you still have interest for it we could prioritize it (and ask for feedbacks :))