Compare
A Mixpanel alternative you run on your own server.
Mixpanel is a hosted service: your events go to Mixpanel, and you choose which region they are kept in. Lyraflow does the same kind of work on a machine you run, so the events never go anywhere else. It is also much younger and much smaller, and this page says where.
Every claim about Mixpanel on this page links Mixpanel's own documentation, and each was checked on 22 September 2026. If something here has gone out of date, tell us and it will be corrected.
The short version
| Mixpanel | Lyraflow | |
|---|---|---|
| Where it runs | Mixpanel's infrastructure, hosted on Google Cloud. Its documentation describes no self-hosted option | Your server, under Docker. There is no hosted version |
| Where the data is kept | US by default, or the EU or India, chosen per project when it is created | Wherever you put the server |
| Getting raw events out | A raw event export API, returning JSON lines | Already in your own ClickHouse database |
| Merging two known user ids | Not possible under the Simplified ID Merge API | An alias call merges them, permanently |
Where your data lives
Mixpanel stores data in the US by default, on Google Cloud, and offers an EU data residency programme and an India one. The region is chosen per project when the project is created. Mixpanel's documentation says a project created in the wrong region has to be replaced with a new one, and that Mixpanel cannot help migrate it. Mixpanel's subprocessor list names Google Cloud as the host of its analytics platform. None of the Mixpanel pages checked for this comparison describe a self-hosted or on-premises deployment.
Lyraflow has no regions because it has no servers of its own. Events go to ClickHouse and identity to Postgres, both in containers on the machine you install it on, and nothing is sent anywhere else. There is no data-processing agreement to sign with Lyraflow, because Lyraflow never receives the data.
Getting your data out
Mixpanel documents several export routes: a raw event export API that returns JSON lines, CSV export from the interface, an API for profiles, an API for report results, and pipelines that sync data to a warehouse or an audience to other tools. Its own documentation notes that deduplication is not applied to a raw export, so an export can contain duplicates.
With Lyraflow there is nothing to ask for, because the database is already yours: you can query ClickHouse directly. Over the API, events can be read a page at a time, and one person's complete record exports as NDJSON for a subject-access request. There is no bulk export endpoint, no scheduled export and no sync to a warehouse or to other tools.
Identity
Mixpanel's default identity system for projects created since April 2024 is the Simplified ID Merge API. When an event first carries both a device id and a user id, the two are merged into one identity cluster, and the user id becomes the identity. Mixpanel's FAQ on that page says it is not possible to merge two user ids together under the Simplified API, and that Mixpanel does not recommend doing so.
Lyraflow binds a device to a person with an identify call, and every
event that device sent before it, as well as after, resolves to that person. When
a device is later bound to someone else, as on a shared computer, the history
splits at that moment: each event belongs to whoever was signed in when it
happened. Two user ids that turn out to be one person, such as after an id
migration, can be merged with an alias call. That merge cannot be
undone. Identity resolution has the
details.
What Mixpanel does that Lyraflow does not
- It runs itself. Mixpanel is a hosted service. Lyraflow is a server you run: HTTPS, backups, upgrades and disk space are yours to look after. If nobody on your team wants that job, a hosted tool is the better choice.
- It sends data onward. Mixpanel documents warehouse pipelines and cohort syncs to other tools. Lyraflow has neither.
- It already has your history. Mixpanel keeps what you have already sent it. Lyraflow has no importer, and its ingest API clamps every timestamp to within 24 hours of arrival, so months of past events cannot be sent to it over HTTP. Moving means starting from the first event Lyraflow receives.
And Lyraflow's own gaps. There is no session replay, no feature flags, no experiments and no surveys. There is no path analysis, no alerting, no scheduled export and no email digest. A funnel and a retention grid cannot be broken down by a dimension the way a trend can. There is one admin account and no roles. Ingest never fills country, region or city yet, because there is no GeoIP lookup (#12); the countries in the demo are generated seed data. There is no published container image, so the install builds one from the checkout. Lyraflow's first commit was on 1 August 2026, it is built by one person, and as far as we know nobody outside the project runs it in production yet.
Who it suits
Lyraflow suits a team that wants funnels, retention, trends and segments over its own users, would rather the events never left its own infrastructure, and can run three containers. It does not suit a team that wants a hosted service, needs its historical data carried over, or needs the product to be further along than Lyraflow is today. The live demo is the quickest way to tell which you are, and getting started takes about five minutes.
Sources
Every Mixpanel page this comparison was checked against, on 22 September 2026:
- https://mixpanel.com/legal/subprocessor-list/
- https://docs.mixpanel.com/docs/privacy/eu-residency
- https://docs.mixpanel.com/docs/privacy/in-residency
- https://docs.mixpanel.com/docs/export-methods
- https://docs.mixpanel.com/reference/raw-data-export-api
- https://docs.mixpanel.com/docs/tracking-methods/id-management
- https://docs.mixpanel.com/docs/tracking-methods/id-management/identifying-users-simplified
There is a separate page comparing Lyraflow with PostHog, which can also be self-hosted.