Langfuse or MLflow: when each one fits
Choose Langfuse when LLM tracing, prompt management and evaluation are the center of the work and no other tool needs to share the same workflow. Its core features and APIs are available in the MIT-licensed open source edition without limits, and self-hosted deployments run the same codebase as Langfuse Cloud. The cost is an operating footprint of its own: a self-hosted deployment runs a web and a worker container backed by PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage. Teams should confirm that they are willing to run and upgrade all of those components before committing, because the v3 to v4 upgrade guide sets specific minimum versions (ClickHouse 25.12 or later, PostgreSQL 15 or later, Redis 7.0 or later) and calls for extra ClickHouse disk headroom when backfilling history.
MLflow fits better when an MLflow server already runs for classic ML experiment tracking and the model registry, or when the team does mixed ML and LLM work and wants one place for both. MLflow is Apache-2.0 licensed, its tracing is fully OpenTelemetry-compatible, and it covers evaluation with more than 50 built-in metrics and LLM judges, plus prompt management. A self-hosted MLflow server can start on its default SQLite backend, with PostgreSQL suggested for scaling and artifacts on local disk or object storage, which is a smaller first step than the Langfuse stack. Check whether the features you need sit in the open edition: SSO and custom authentication plugins are documented for self-hosted MLflow, and workspace-level permissions require a SQL database backend.
Which platform fits which team scenario
This table maps common team situations to the platform that fits them better and the condition under which the other one wins. Read each row against your existing estate, your data platform and your compliance needs, not against a general ranking of the two tools.
| Team scenario | Better fit | Reason and condition for the other platform |
|---|---|---|
| Existing MLflow estate for classic ML and a small LLM addition | MLflow | MLflow already covers experiment tracking, the model registry and deployment, and its tracing and evaluation extend the same server. Langfuse wins if LLM trace volume or product-facing analytics outgrow the MLflow server and you accept a second system. |
| Pure LLM product team with no classic ML models | Langfuse | Langfuse is built around LLM traces, sessions, prompt versions and evaluations, with no model registry to carry. MLflow fits if the team later needs the same server for models, agents and LLM work together. |
| Platform team already operating ClickHouse | Langfuse | Langfuse uses ClickHouse for trace analytics next to PostgreSQL and Redis or Valkey, so the database skills already exist. The condition is that the team can size ClickHouse memory and disk and plan the documented migrations, otherwise MLflow's SQL backend is the lighter start. |
| Regulated team that needs RBAC, SCIM and retention controls | Confirm before choosing | Langfuse lists project-level RBAC, retention, audit logs and SCIM behind an Enterprise license key, so the key and its cost must be in the quote. MLflow lists SSO, custom authentication plugins and workspace permissions that need a SQL backend. Ask each vendor which controls your assessor will test. |
| One tool for models and LLMs under one governance process | MLflow | MLflow covers observability, evaluation, prompt management, the AI Gateway and the model registry in one Apache-2.0 project. Langfuse wins if the model side is already handled elsewhere and the LLM team wants a dedicated tool with its own release cadence. |
| Team that wants OpenTelemetry-native tracing from many services | Either, verify the instrumentation | MLflow Tracing is documented as OpenTelemetry-compatible with GenAI semantic conventions. Langfuse also accepts OpenTelemetry. Test both with your actual span attributes before deciding, since mapping details matter more than the headline claim. |
| Team that expects to self-host with minimal components at first | MLflow | The self-hosting docs describe starting with mlflow server on a default SQLite backend, with PostgreSQL suggested for scaling. Langfuse needs PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage from the start, which is a larger footprint even for a test. |
| Team with data residency rules that keeps all traces inside its own cluster | Either, confirm storage and telemetry settings | Both can run inside your infrastructure. Confirm in writing which artifacts, trace payloads and telemetry each deployment sends, and who holds the license keys and backups. |
How each platform is built and what it asks you to run
A self-hosted Langfuse deployment is a set of application containers and stateful services, and each one has its own sizing, scaling and failure mode. The Langfuse Web container serves the user interface and APIs, and the Langfuse Worker container handles asynchronous event processing. The stateful dependencies are PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible blob storage, and the self-hosting documentation lists all of them as part of the standard footprint.
- Two application containers: Web answers requests from users and SDKs, while the worker processes queued events. A backlog in ingestion usually shows up in the worker first.
- ClickHouse as the analytics store: The scaling guide lists a minimum of 2 CPU and 8 GiB of memory, with at least 16 GiB for larger deployments. This is the largest sizing decision in the stack.
- PostgreSQL and Redis or Valkey: The guide lists 2 CPU and 4 GiB for PostgreSQL and 1 CPU and 1.5 GiB for Redis or Valkey, which are the smaller but still stateful pieces you must back up and monitor.
- S3-compatible blob storage: Your storage team must provision and govern the bucket, including retention, access policy and backup.
Before you commit, confirm that your team can operate all four stateful dependencies, and name an owner for each one.
Langfuse documents two deployment paths that matter for planning. Docker Compose on a single VM is documented for testing and does not provide high availability. Kubernetes, deployed with Helm or Terraform on AWS, Azure or GCP, is the documented path for production. The choice shapes how much platform work your team takes on before the first trace arrives, and it determines how you scale later.
- Compose for evaluation: Useful for a proof of concept or a non-production environment. Plan a separate production build instead of promoting a single VM.
- Kubernetes for production: Helm or Terraform gives you repeatable environments, but your platform team owns cluster lifecycle, ingress, secrets and storage classes.
- Scaling the worker: Langfuse recommends scaling worker containers on CPU load, which keeps ingestion healthy without changing the data model.
- Splitting the web tier: Under heavy ingestion, the scaling guide recommends separating langfuse-web into an ingestion deployment and a user interface deployment, so dashboard use does not compete with trace intake.
- Managed services: Decide early which of the four stateful dependencies you will run yourself and which you will buy as managed services, and confirm with Langfuse how each option is supported.
Ask your Langfuse contact which dependencies the production reference deployment assumes, and which parts your team must provide.
A self-hosted MLflow deployment starts with the mlflow server command and two storage decisions: a backend store for metadata and an artifact store for files. Since MLflow 3.7.0, SQLite is the default backend store, which is simple to start with but is not the configuration the self-hosting documentation suggests for scaling. MLflow suggests PostgreSQL for that purpose. The footprint is therefore one server process, a SQL database and artifact storage, which is a smaller set of moving parts than a full Langfuse stack.
- Backend store: Start with SQLite only for evaluation. Move to PostgreSQL before multiple teams write traces and experiments to the same server.
- Artifact store: Artifacts can live on local disk or in S3, GCS or Azure Blob Storage. Local disk complicates high availability and backup, so confirm the storage design with your platform team.
- Official Helm chart: MLflow publishes a Helm chart for Kubernetes, so you can avoid writing your own manifests, but you still own ingress, TLS and database backups.
- Authentication: The documentation covers basic HTTP authentication, SSO and custom authentication plugins. Confirm which option fits your identity provider before go-live.
- Workspaces: Opt-in workspaces with workspace-level permissions require a SQL database backend, so the SQLite default cannot support them.
Verify the backend and artifact storage choices, and the authentication method, before you load any production data.
Langfuse publishes a clear rule for upgrades: updates within a major version are non-disruptive, and database migrations run automatically when the container starts. Major versions, such as v3 to v4, follow dedicated migration guides. The v3 to v4 guide requires ClickHouse 25.12 or later (26.4 recommended), PostgreSQL 15 or later and Redis 7.0 or later, and it moves to an observations-first ClickHouse data model. Automatic migrations mean a rollout can change your schema, so your on-call runbook needs a backup step before every upgrade.
- Within a major version: Expect routine rollouts, but still take a database backup because migrations run at startup.
- Major version upgrades: Follow the dedicated guide, check dependency versions first, and schedule the change as a project rather than a patch window.
- Disk headroom for backfills: The v4 guide advises about 3x ClickHouse disk headroom when backfilling historic data, which is the upgrade item most likely to fill a volume.
- MLflow upgrades: The supplied documentation does not set out an upgrade policy for the server or its schema, so ask MLflow for its migration guidance and test a copy of your backend first.
- On-call coverage: Confirm which alerts page your team for each stateful dependency, and who can restore ClickHouse or PostgreSQL if an upgrade fails.
Before you choose either platform, write down the upgrade window, the backup owner and the rollback steps for each component.
What each architecture means for day-two operations
Langfuse and MLflow ask for different things once they are running. The cards below cover the stores you size, the minimums you budget for, how workspaces and artifacts are handled, and how upgrades differ, so you can test each claim against your own environment before committing.
ClickHouse memory and disk
Langfuse keeps traces in ClickHouse, so that store sets most of the sizing work. The scaling guide lists 2 CPU and 8 GiB for ClickHouse, with at least 16 GiB of memory for larger deployments. Ask your team how trace volume and retention will grow disk use, and plan for the store to be the largest line item on the host. MLflow does not add this second analytical store to your stack.
Disk headroom for backfills
The Langfuse v3 to v4 guide advises about 3x ClickHouse disk headroom when backfilling historic data into the observations-first model. This is a one-time cost during migration, but it can exceed the steady-state disk need. Confirm the size of your existing trace history before scheduling the upgrade, and reserve the headroom in your storage plan rather than discovering it mid-migration.
Minimum resources per component
Langfuse's scaling guide sets minimums per service: 2 CPU and 4 GiB for web, worker and PostgreSQL, and 1 CPU and 1.5 GiB for Redis or Valkey. Those figures add up to a multi-container footprint before any growth. Under heavy ingestion, Langfuse suggests scaling workers on CPU load and splitting web into ingestion and UI deployments. Budget for those replicas from the start.
SQL backend for MLflow workspaces
MLflow's opt-in workspaces, which provide workspace-level permissions, require a SQL database backend. The default SQLite store, used since MLflow 3.7.0, will not support this model. Plan a PostgreSQL instance from the outset if you expect multiple teams to share one server with separate permissions. Confirm with your platform team whether that database will be managed or self-run, since it becomes a shared dependency.
Artifact storage choices
MLflow stores artifacts on local disk or in S3, GCS or Azure Blob Storage, separate from its metadata store. Langfuse depends on S3-compatible blob storage as a required component. For a self-hosted MLflow server, decide early whether artifacts live on a shared object store that multiple hosts can reach, because local disk ties the server to one machine and complicates recovery.
Upgrade paths differ
Langfuse says updates within a major version are non-disruptive and run database migrations automatically at startup, while major versions such as v3 to v4 follow dedicated guides. MLflow upgrades depend on its own release line and database schema changes. Before adopting either, test an upgrade against a copy of your database and object store, and confirm how the team will roll back if a migration fails.
Tracing, evaluation and prompt features side by side
This table compares how Langfuse and MLflow handle OpenTelemetry tracing, evaluation, prompt management and access controls in a self-hosted deployment. Entries that name an Enterprise license key apply only to that paid tier, and entries marked to confirm should be checked with the vendor before you commit. The main takeaway is that MLflow documents broader built-in evaluation and standards support, while Langfuse places several governance controls behind its Enterprise key.
| Capability | Langfuse | MLflow |
|---|---|---|
| OpenTelemetry support | Accepts OpenTelemetry ingestion; confirm which GenAI semantic convention attributes your SDK emits | Fully OpenTelemetry-compatible with native support for GenAI semantic conventions for export and ingestion |
| Evaluation metrics and judges | Evaluation in the MIT edition; confirm the built-in metric and LLM judge list for your version | More than 50 built-in evaluation metrics and LLM judges, per the MLflow README |
| Prompt management | Prompt management in the open source edition; protected prompt labels need an Enterprise license key | Prompt management and prompt optimization listed in the README; confirm the registry features you need |
| Role-based access control | Project-level RBAC roles need an Enterprise license key; confirm the default roles in the free edition | Opt-in workspaces with workspace-level permissions, which require a SQL database backend; confirm permission granularity |
| Single sign-on | SSO is documented; confirm which providers work without an Enterprise license key | SSO and custom authentication plugins on the self-hosted server, plus basic HTTP authentication |
| Audit logs | Audit logs need an Enterprise license key | Not covered in the supplied facts; confirm with the MLflow self-hosting documentation |
| SCIM provisioning | Org management API with SCIM needs an Enterprise license key | Not covered in the supplied facts; confirm with your identity provider and the MLflow release you run |
| Workspace or tenant separation | Organizations and projects; organization creators need an Enterprise license key | Opt-in workspaces need a SQL backend; confirm how they interact with your authentication setup |
Licenses, editions and what is paid for
Langfuse is open core. The repository is MIT Expat licensed, except for content under the ee/, web/src/ee/ and worker/src/ee/ directories, which fall under a separate enterprise license. Langfuse states that all core features and APIs are available in the MIT-licensed open source version without limits, and that self-hosted deployments run the same codebase as Langfuse Cloud. The license boundary is therefore about specific add-on features, not about core tracing or evaluation.
- Core features: tracing, evaluations and the APIs are documented as available in the MIT edition without limits.
- Enterprise directories: code under the
eepaths carries a commercial license, which you should review with your legal team before modifying those paths. - Same codebase: self-hosted and cloud deployments share one codebase, so feature behavior should match across both.
- Plan for a legal read: confirm the current license text in the repository before you rely on it for procurement.
Ask Langfuse to confirm in writing which features your use case depends on, and whether any of them sit in the enterprise directories.
Some self-hosted Langfuse features need an Enterprise license key. The Langfuse license key documentation lists these as project-level RBAC roles, protected prompt labels, data retention policies, audit logs, server-side data masking, UI customization, organization creators, the organization management API with SCIM, and the instance management API. If your governance model depends on any of these, the open source edition alone may not meet it.
- Access control: project-level RBAC roles and organization creators.
- Prompt governance: protected prompt labels.
- Data handling: data retention policies and server-side data masking.
- Accountability and identity: audit logs, plus the organization management API with SCIM for provisioning.
- Administration: UI customization and the instance management API.
Map each requirement from your security or compliance team to this list before you size the deployment. Confirm with Langfuse how the key behaves in your environment, since the Enterprise edition is covered on its own comparison page.
Langfuse's self-hosted pricing page lists a free open source plan and a custom-priced Self-Hosted Enterprise plan. The Enterprise plan adds a named support engineer, solutions architect access and a support SLA. The price is not published, so it follows from the scope and terms you agree with the vendor. Your total cost also includes the infrastructure you run for PostgreSQL, ClickHouse, Redis or Valkey and blob storage, plus the staff time to operate it.
- Free plan: the open source edition, which you run and support yourself.
- Enterprise plan: custom-priced, recurring, and adds named support, architect access and a support SLA.
- Infrastructure: your own cloud or data center costs, which recur and scale with ingestion volume.
- Services: DeployOpen can implement and operate a self-hosted deployment under a fixed-scope agreement, which is separate from the vendor's plan.
When requesting a quote, ask the vendor what the SLA covers, how the license key is issued and renewed, and what happens to enterprise features if the key lapses.
MLflow is licensed under Apache-2.0, according to the mlflow/mlflow GitHub license metadata. The MLflow README describes tracing, evaluation, prompt management and an AI Gateway as part of the platform. The facts supplied do not describe a paid MLflow tier, so this comparison does not assume one exists. Managed MLflow is offered by several cloud providers, and those services carry their own commercial terms.
- License: Apache-2.0 for the open source project.
- Managed services: Databricks, AWS SageMaker, Azure Machine Learning, Nebius and GCP are listed in the self-hosting docs, each with its own pricing and terms.
- No paid tier described: the facts do not describe a paid MLflow edition, so confirm with the maintainers or the project's documentation before you assume one.
Confirm the license text and any commercial offerings directly with the project and the provider you plan to use.
Self-hosted MLflow supports basic HTTP authentication, SSO and custom authentication plugins, and it has an official Helm chart. Workspaces are opt-in, and workspace-level permissions require a SQL database backend. The default backend store is SQLite since MLflow 3.7.0, and the self-hosting docs suggest PostgreSQL for scaling. So, if you want per-team isolation, you need to plan for a SQL database from the start rather than adding it later.
- Authentication: basic HTTP authentication, SSO and custom plugins are available in the self-hosted server.
- Workspaces: opt-in, with workspace-level permissions that require a SQL backend.
- Default storage: SQLite as the default backend store since MLflow 3.7.0.
- Scaling: PostgreSQL is suggested in the docs for larger deployments.
Confirm which authentication and workspace features your version supports, and test them against your identity provider before you commit to the design.
Does an existing MLflow estate make a second tool unnecessary?
An existing MLflow server is enough only when your LLM work is covered by what MLflow already does and you can accept its operating model. Start by listing the workflow your team actually runs: which traces you need, how you evaluate them, and where prompts are versioned and promoted. MLflow Tracing is fully OpenTelemetry-compatible and supports the OpenTelemetry GenAI semantic conventions, MLflow ships more than 50 built-in evaluation metrics and LLM judges, and its prompt management sits in the same platform as experiment tracking and the model registry. If your agents and evaluations fit that scope, adding a second system mostly duplicates tracing and adds a ClickHouse cluster to run. Confirm with your MLflow version and the MLflow self-hosting documentation that the features you depend on are available in your deployment mode.
The test should then check for Langfuse-specific controls. Self-hosted Langfuse needs an Enterprise license key for project-level RBAC roles, protected prompt labels, data retention policies, audit logs, server-side data masking and SCIM provisioning. If a regulator or internal policy requires retention periods per data class, prompt label protection for production releases, or masking before storage, check whether MLflow's built-in options and your SSO and authentication setup meet those requirements, or whether you would need to build them. Ask for written answers on each control rather than assuming parity from feature names. The Langfuse license key documentation lists the full set of gated features.
Trace volume is the cost test. Langfuse's stack runs ClickHouse, PostgreSQL, Redis or Valkey and S3-compatible storage, and its scaling guide lists at least 2 CPU and 8 GiB for ClickHouse, with 16 GiB of memory for larger deployments. Those resources, the Langfuse v3 to v4 migration guidance on ClickHouse versions and disk headroom, and the on-call work they create are recurring costs. A second tool is justified when your expected trace volume and retention needs make the MLflow SQL backend the weak point, or when your security team requires a separate platform with its own access model. It is hard to justify when your MLflow estate is small, your traces are modest, and the features you need are already present. Ask your team to estimate trace volume and retention in writing, then price both paths using the same assumptions.
What drives running cost for each platform
Running cost for Langfuse and MLflow comes from the components each one keeps online, the people who operate them and the support you buy around them. The cards below separate what you pay once from what recurs, and what to ask for in a quote before you commit.
Langfuse minimum infrastructure per component
The Langfuse scaling guide lists 2 CPU and 4 GiB for web, worker and PostgreSQL, 1 CPU and 1.5 GiB for Redis or Valkey, and 2 CPU and 8 GiB for ClickHouse, with at least 16 GiB of ClickHouse memory for larger deployments. These are recurring compute costs that stay on whether or not traffic arrives. Ask for the sizing your ingestion volume requires, since the guide also recommends splitting langfuse-web under heavy ingestion.
ClickHouse sizing and disk headroom
ClickHouse holds the trace and analytics data, so it usually drives storage cost more than any other component. The v3 to v4 guide advises about 3x ClickHouse disk headroom when backfilling historic data, a one-time spike you should budget for during migration. Ongoing storage grows with trace volume and your retention settings, so ask how retention is configured and what disk growth the vendor expects per month of traffic.
MLflow server and SQL backend
A self-hosted MLflow server runs on a single process that defaults to SQLite, and the docs suggest PostgreSQL for scaling. Artifacts go to local disk or S3, GCS or Azure Blob Storage, so storage cost depends on the object store you choose. Recurring cost is the server host, the database you run or rent, and the bucket. Confirm which backend and artifact store your quote assumes, because SQLite is not a fit for shared multi-team use.
Skills to run each platform
Running Langfuse means operating ClickHouse, PostgreSQL, Redis or Valkey and object storage, so the team needs people who can tune a columnar database and handle its migrations. Running MLflow means administering a tracking server, a SQL database, authentication and artifact storage, which is closer to familiar web service operations. Price the staff time for these skills as a recurring cost, and check whether your current platform team already covers them.
Support options and what they cost
Langfuse Enterprise is a custom-priced plan that adds a named support engineer, solutions architect access and a support SLA, while the open source plan has no bundled support. MLflow's managed options come from Databricks, AWS SageMaker, Azure Machine Learning, Nebius and GCP, each billed on its own terms. Compare what each support tier covers against your on-call needs, and ask vendors for the SLA text in writing.
Upgrades and edition gating
Langfuse updates within a major version apply database migrations at startup, while major upgrades follow dedicated migration guides that carry their own ClickHouse, PostgreSQL and Redis minimums. MLflow is Apache-2.0 for the core, but paid or enterprise features such as workspaces with workspace-level permissions need a SQL backend and planning. Recurring cost includes the upgrade window you staff each year. Ask which features sit behind an Enterprise key or managed plan before you commit to a design that depends on them.
Moving traces and prompts between Langfuse and MLflow
This sequence moves LLM traces, prompts and datasets from one platform to the other without losing history or interrupting applications. The run-both-in-parallel phase is what makes the cutover reversible.
Inventory traces, prompts and datasets
The platform owner and the team that maintains each LLM application list what lives in the current store: trace volumes by application, prompt names and versions, evaluation datasets, scores and the dashboards and alerts that read from them. Record which prompts are referenced by label in production code, because labels do not carry over on their own. The step is done when the list is signed off by the application owners and every item has a named destination or a decision to drop it.
Map OpenTelemetry instrumentation
An engineer checks how each application sends traces today, whether through the Langfuse SDK, direct OpenTelemetry export or MLflow autologging, and confirms which GenAI semantic convention attributes the spans carry. MLflow Tracing is documented as OpenTelemetry-compatible with support for the GenAI semantic conventions, and Langfuse accepts OpenTelemetry, so spans are the most portable layer. Confirm attribute mapping for token usage, model names and tool calls in a test trace on both platforms. The step is done when a sample trace from each application renders with the fields the team relies on.
Run both platforms in parallel
Configure each application to send traces to the new platform while keeping the existing export active, so both stores receive the same spans. Set up a small test project first, then enable the second destination for production traffic. Ask the platform team to confirm the self-hosted footprint on the new side, since it must run its own database and storage services alongside the old ones during this window. The step is done when span counts and error rates match between the two stores for a full business cycle chosen by the application owners.
Backfill history and check disk headroom
Export historic traces from the source store and import them into the target, starting with the windows that analysts and evaluators actually query. For Langfuse as the target, the v3 to v4 guide advises about 3x ClickHouse disk headroom when backfilling historic data, so size storage before the import starts. Migrating into MLflow depends on the SQL backend and artifact storage you chose, so confirm capacity there too. The step is done when a random sample of backfilled traces matches the source by ID, timestamp and token counts.
Rebuild prompts, evaluators and access roles
Recreate prompt versions and labels in the target registry, then rebuild evaluators, judges and dashboards, which do not transfer with the traces. Map user and team access to the new platform's roles. In Langfuse, project-level RBAC, protected prompt labels, data retention and audit logs need an Enterprise license key, so confirm which controls the team requires before assigning roles. The step is done when each evaluator produces scores on a test dataset and each prompt label resolves to the expected version in the application.
Cut over SDK endpoints
Change the trace destination in each application configuration, deploy it through the normal release process and watch ingestion for the first day of production traffic. Keep the old export disabled but its store running so a rollback is a configuration change. Owners of each application sign off on their own traces. The step is done when every application reports traces only to the new platform and no application has been rolled back.
Retire the old store
After the agreed observation period, stop the old export, archive data your retention policy requires and decommission the old services, including their databases, queues and object storage buckets. Record what was archived, where, and who approved deletion. Confirm that compliance evidence still points to the correct system of record. The step is done when the old platform is read-only or offline, the archive is verified and the decommission is documented.
What implementing each involves and where projects run long
A Langfuse deployment starts with sizing and component ownership. A self-hosted Langfuse stack runs Langfuse Web and Langfuse Worker, backed by PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible blob storage. The scaling guide lists minimum resources of 2 CPU and 4 GiB for web, worker and PostgreSQL, 1 CPU and 1.5 GiB for Redis or Valkey, and 2 CPU and 8 GiB for ClickHouse, with at least 16 GiB of ClickHouse memory for larger deployments. Decide early who operates ClickHouse, how it is backed up, and whether the team will split langfuse-web into separate ingestion and user interface deployments under heavy load. Design SSO and RBAC before go-live: project-level roles, protected prompt labels, audit logs and SCIM provisioning are Enterprise license key features, so confirm which of them your controls require before you finalize the identity model.
An MLflow server is simpler to start but carries its own design choices. The default backend store is SQLite since MLflow 3.7.0, and the self-hosting docs suggest PostgreSQL for scaling, so the SQL backend decision should be made before any traces or runs accumulate. Artifacts go to local disk or to S3, GCS or Azure Blob Storage, and the artifact root needs its own access controls and retention. Authentication options include basic HTTP auth, SSO and custom plugins, and opt-in workspaces with workspace-level permissions require a SQL database backend. Teams should decide whether tenancy is per workspace or per experiment, and confirm how instrumentation with OpenTelemetry is enforced across services.
Projects tend to run long in four places. ClickHouse migrations are the most common: Langfuse's v3 to v4 guide requires ClickHouse 25.12 or later (26.4 recommended), moves to an observations-first data model and advises about 3x ClickHouse disk headroom when backfilling historic data, so plan a rehearsal on a copy of production data. Auth integration often slips because SSO, SCIM and role mapping touch the identity provider, not only the tool. Multi-team tenancy is the third risk, since project boundaries, role design and workspace permissions are hard to change once dashboards and prompts exist. Ask any implementation partner for a written scope that names these items, the backfill plan and the rollback path for each upgrade.
Questions buyers ask before choosing or hiring help
Is Langfuse free to self-host?
Yes, the core product is free to self-host under the MIT license. Langfuse states that all core features and APIs are available in the MIT-licensed open source version without limits, and self-hosted deployments use the same codebase as Langfuse Cloud. The license exception is the code in the ee directories, which falls under a separate enterprise license. Your costs are the infrastructure you run (web and worker containers, PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible storage), the engineering time to operate them, and any paid support you choose. Confirm the current terms in the Langfuse LICENSE file before you rely on them.
What does the Langfuse Enterprise license key add?
The key unlocks a specific set of features rather than the core tracing and evaluation product. Per the Langfuse license key documentation, these include project-level RBAC roles, protected prompt labels, data retention policies, audit logs, server-side data masking, UI customization, organization creators, and the org management API with SCIM and the instance management API. The Self-Hosted Enterprise plan also adds a named support engineer, solutions architect access and a support SLA, with custom pricing. If your compliance or identity team requires audit logs, SCIM or retention controls, budget for the key. If you do not, the open source edition may be enough. Ask Langfuse what happens to these features if the key lapses.
Does MLflow alone cover LLM tracing and evaluation?
MLflow covers much of the same ground, so it can replace a second tool if your team already runs it. MLflow is Apache-2.0 licensed and describes observability, evaluation, prompt management and an AI Gateway. MLflow Tracing is fully OpenTelemetry-compatible and supports the OpenTelemetry GenAI semantic conventions, and the README lists more than 50 built-in evaluation metrics and LLM judges. The differences lie in the data model and operating footprint. Langfuse runs on ClickHouse for analytics, while MLflow stores its metadata in a SQL backend. If your estate is built around MLflow experiments, a second tool adds a platform to patch, back up and govern. Test the trace volume and query patterns you expect before deciding.
How much effort does each self-hosted stack take to run?
Langfuse takes more moving parts, while MLflow takes less to start. A self-hosted Langfuse deployment runs two application containers plus PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage. Langfuse documents Docker Compose on a single VM for testing with no high availability, and Kubernetes with Helm or Terraform for production. Its scaling guide lists minimum resources of 2 CPU and 4 GiB for web, worker and PostgreSQL, 1 CPU and 1.5 GiB for Redis or Valkey, and 2 CPU and 8 GiB for ClickHouse, with at least 16 GiB of ClickHouse memory for larger deployments. MLflow starts with mlflow server and defaults to SQLite since MLflow 3.7.0, with PostgreSQL suggested for scaling and artifacts on local disk or object storage. Your team must still own backups, upgrades and access control for either stack.
Can our team run Langfuse or MLflow in-house?
Often yes, if you already operate PostgreSQL, object storage and Kubernetes or VM tooling. The deciding factors are the number of platforms your team already runs, the ClickHouse skills available, and how much trace data you will keep. Langfuse's v3 to v4 upgrade guide requires ClickHouse 25.12 or later, PostgreSQL 15 or later and Redis 7.0 or later, and advises about 3x ClickHouse disk headroom when backfilling historic data. That makes major upgrades a planned project. MLflow's operating load is lighter if you accept SQLite for a small team, but production use with multiple users needs a SQL backend, authentication and artifact storage decisions. Be honest about who will be on call for each.
What should we ask a services partner for in a fixed-scope quote?
Ask for a written scope that names each component, environment and deliverable before work begins. DeployOpen works mostly on fixed-scope engagements, so the quote should follow from that scope rather than from a published price list. Request the list of components to deploy and harden (for Langfuse, web, worker, PostgreSQL, ClickHouse, Redis or Valkey and object storage; for MLflow, the server, SQL backend, authentication and artifact store), the identity integration you need, the backup and upgrade process, the evidence produced for compliance reviews, and the handover documentation. Also ask which items recur, such as retainers for support, upgrades and continuous testing, and which are one-time. Confirm what is excluded, including license keys and managed cloud services.
Does a fixed-scope engagement cover ongoing upgrades?
Not by default, so confirm it in the written scope. DeployOpen describes ongoing support, upgrades and continuous testing as retainers that are separate from the initial fixed-scope work. Langfuse applies database migrations automatically at startup for updates within a major version, but major upgrades follow dedicated migration guides that take planning. MLflow releases also need testing against your authentication and storage setup. Ask the partner who performs each upgrade, how a rollback is handled, and whether the retainer covers both applications and the underlying databases. Make sure the cost of recurring upgrades is visible before you choose a tool.
How DeployOpen helps choose and implement either platform
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside the client's own infrastructure, including cloud accounts, data centers and air-gapped networks. For a Langfuse vs MLflow decision, that means the work can cover either platform, or both, on the infrastructure you already run. DeployOpen helps evaluate the two options without favoring either. Its role is to map your requirements to what each platform needs to run, such as the ClickHouse, PostgreSQL, Redis or Valkey and blob storage footprint Langfuse expects, or the MLflow server with a SQL backend store and artifact location you would configure. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies produce those, and DeployOpen prepares the systems, controls and evidence they assess.
Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. A useful first step is a written list of the trace, evaluation and prompt management workflows your teams need, the identity model you must integrate (for example, SSO or the Langfuse Enterprise features such as project-level RBAC and SCIM, which need a license key), and the data retention and audit requirements you must meet. Those items determine whether the MIT-licensed Langfuse edition or an MLflow deployment fits, and they define what an implementation quote should cover. Ask any partner, DeployOpen included, to confirm current versions, licensing terms and feature availability against the vendor's own documentation before scoping.
After go-live, ongoing support, upgrades and continuous testing are available as retainers. This matters for both platforms: Langfuse major upgrades follow dedicated migration guides, and MLflow self-hosting changes with each release line. A retainer can keep the stack patched, backups tested and upgrade paths documented as your observability estate grows. If you already run MLflow for experiment tracking and the model registry, the question of whether a second tool is needed is also a scoping task, and DeployOpen can document the findings so your architecture and compliance teams can review them.
