> Part of the walkerOS documentation. Project overview and full index: # walkerOS vs. Jitsu [Jitsu](https://jitsu.com/) is an open-source data collection platform founded in 2020 (Y Combinator S20) that positions itself as a Segment alternative. It focuses on streaming event data to data warehouses. ## Quick comparison[​](#quick-comparison "Direct link to Quick comparison") | Feature | Jitsu | walkerOS | | -------------------- | ------------------------------------------------------------------------- | ------------------------------------------------- | | Open-source | Yes (MIT) | Yes (MIT) | | Company location | USA | Germany | | Data hosting | Self-host anywhere, US-hosting for Cloud version | Self-host anywhere, EU-hosting for the hosted app | | Pricing | Free up to 200k events, then start at $99 per month for 2M events (Cloud) | Free, self-hosted (Paid support available) | | Consent handling | Config option (privacy mode) | First-class (consent in events) | | Event model | Schema-less, freeform naming | Structured entity-action | | Primary destinations | Data warehouses | Warehouses + ad platforms | | Composable tagging | No | Yes (tag once in component, use everywhere) | ## Who should use what?[​](#who-should-use-what "Direct link to Who should use what?") ### Choose Jitsu if[​](#choose-jitsu-if "Direct link to Choose Jitsu if") * You're migrating from Segment and want API compatibility * You need included ClickHouse storage on the free tier * Data residency in the EU is not a requirement ### Choose walkerOS if[​](#choose-walkeros-if "Direct link to Choose walkerOS if") * You need consent state in every event, built into the event model for GDPR * You're routing to ad platforms (Meta, Google) and need match quality * You're a European company needing pure EU data hosting * You want structured event naming (entity-action prevents chaos at scale) ## Key differences[​](#key-differences "Direct link to Key differences") ### Consent handling[​](#consent-handling "Direct link to Consent handling") **Jitsu:** A "privacy mode" can be enabled in the configuration. When it is active, Jitsu uses fingerprints instead of cookies and truncates IP addresses. Consent is a configuration setting, though, and the consent state does not travel with events to destinations. **walkerOS:** Every event carries its consent state, so destinations always know what permissions were granted. For GDPR accountability, this means you can prove what consent existed when each event was collected. ### Data residency[​](#data-residency "Direct link to Data residency") **Jitsu:** A US-based company. Jitsu's data processing agreement states that Jitsu Cloud's primary processing takes place in the United States; for EU data residency you self-host. For EU companies collecting personal data (IP addresses, user IDs, behavioral data) in Jitsu Cloud, this can raise Schrems II compliance concerns. **walkerOS:** A German company. The open-source software can be self-hosted on pure EU infrastructure, which removes transatlantic data transfer concerns entirely. The hosted walkerOS app ([app.walkeros.io](https://app.walkeros.io)) also runs on EU infrastructure. ### Event model[​](#event-model "Direct link to Event model") **Jitsu:** Schema-less by design. It accepts any JSON, auto-creates warehouse columns, and uses freeform event naming (like Segment's "Product Viewed"). That is flexible, but over time it can lead to inconsistent naming across teams and messy warehouse schemas. **walkerOS:** Uses structured entity-action naming (`product view`, `order complete`), so you always know which entity was involved and what action occurred. Optional contracts can validate events at collection time and catch issues before they reach your warehouse. ### Destination focus[​](#destination-focus "Direct link to Destination focus") **Jitsu:** Built primarily for streaming to data warehouses (BigQuery, Snowflake, Redshift, ClickHouse, PostgreSQL), with the warehouse as the core destination. **walkerOS:** Destination-agnostic, with strong support for ad platforms. You can send events to warehouses and to Meta/Google with high match quality for conversion optimization, which matters when analytics and marketing need the same event stream. ### Tagging approach[​](#tagging-approach "Direct link to Tagging approach") **Jitsu:** A JavaScript SDK similar to Google Analytics. You add a tracking script and call tracking functions in your code. It is quick to start, but the tracking code lives apart from your components. **walkerOS:** HTML attribute-based tagging with first-class React/Next.js support. You add `data-elb` attributes to components, and events are captured automatically from user interactions. The tracking lives with your components instead of in a separate tracking layer. ### Cost[​](#cost "Direct link to Cost") **Jitsu:** Free cloud tier up to 200k events/month with included ClickHouse. Business plans start at $99/month for 2M events. Self-hosted is free (MIT). **walkerOS:** The open-source software is free with no event limits, and when you self-host you pay for your own infrastructure. The hosted app adds managed deploys and live observability. Optional paid services include implementation support and SLAs. ## The trade-off[​](#the-trade-off "Direct link to The trade-off") Jitsu optimizes for speed of setup: you add a script tag, start collecting, and let it infer schemas and stream to the warehouse. walkerOS optimizes for data quality over time, with structured events, consent in every event, ad platform routing, and EU hosting. If you need to collect data fast and your destination is a warehouse, Jitsu's simplicity is compelling. If you need consent in every event, route to ad platforms, or require EU data residency, walkerOS is the better fit. ## Can they work together?[​](#can-they-work-together "Direct link to Can they work together?") Yes. You can use walkerOS for event collection and forward the events to Jitsu. walkerOS has no dedicated Jitsu destination: point the [API destination](/preview/pr-720/docs/destinations/api/server.md) at Jitsu's HTTP ingest endpoint and shape the request body with mapping, or, for a Segment-compatible endpoint, set `host` on the [Segment destination](/preview/pr-720/docs/destinations/server/segment.md). walkerOS then handles composable tagging, consent, and structured events on the frontend, and Jitsu streams to the warehouse on the backend. ## Getting started[​](#getting-started "Direct link to Getting started") The [quickstart guide](/preview/pr-720/docs.md) shows how to set up component-level tagging with consent in every event.