What is the same
The shape of the job. You already run a database you are responsible for, you already put a script on your own pages, and you already decided that your visitors' data staying on your infrastructure is worth some operational cost. None of that changes.
The privacy posture is also broadly the same. Falorb sets no third-party cookies, stores no raw IP address, and refuses cross-site tracking permanently, which is the same category of commitment both of those tools make.
What is genuinely different
Plausible reports aggregate statistics and does not model individual users at all. Umami keeps sessions and can show individual visitor activity without identifying personal information. Falorb keeps a person-level record and resolves it across every property you own.
That difference is the reason to move and the thing to think hardest about. It is more data about your visitors, not less, and it makes you the controller of it.
The instrumentation you have not written yet
Neither tool asked you to call an identify function, because neither has anywhere to put the answer. This is the one piece of real work in the migration, and it is small: call identify when somebody signs in, and reset when they sign out.
That single call is what unifies a person across your properties. Anonymous visitors are never joined across domains; identity resolves only on the same identify() id appearing on both, or a click through a decorated link between two of your own domains.
// on sign-in
falorb.identify(user.id, { email: user.email, plan: user.plan })
// on sign-out, so a shared machine does not attribute
// the next person's session to the last one
falorb.reset()Historical data
There is no importer, and building one would be misleading. Both tools store aggregates or sessions that have no person behind them, so importing would produce a history in which nobody exists, sitting underneath reports whose whole premise is that they do.
Keep the old instance running read-only for as long as you want the history, and let Falorb start from the day you install it. Two dashboards for a quarter is cheaper than a year of numbers you cannot trust.
Operational differences to plan for
Umami needs Postgres. Plausible Community Edition needs Postgres and ClickHouse. Falorb needs Postgres, Redis and ClickHouse, so depending on where you are coming from this is either one more thing to back up or two.
In exchange, the collector never writes to a database in the request path, which is what keeps its response time in single-digit milliseconds regardless of what the storage layer is doing.
The usual questions
Can I run Falorb alongside my existing tool?
Yes, and it is the recommended way to switch. Both scripts on the page, both dashboards open, and no decision to make until you trust the new numbers.
Is it worth moving if I only run one site?
Often not. Falorb's advantage is the portfolio and the person graph; on a single site with no sign-in, a lighter tool gives you most of the value for a fraction of the operational surface. The comparison pages say the same thing in more detail.
Run it and see
The quickstart is five commands and needs no account anywhere.