lakeFS

Name: lakeFS
Brand: lakeFS

AI Native

lakeFS is a data version control system that provides Git-like branching, committing, merging, diffing, and rollback as a metadata control plane over object-storage data lakes to enable reproducible ML training, safer experimentation, and production-grade data operations without copying full datasets.

Est 2020|Raised $51M|2 Ref Customers

LinkedIn 7K|Web traffic 46K|FTEs 39

Published Oct 15, 2026

01Common complaints

1. The organization only needs table-format time travel (for example, within Delta Lake or Iceberg tables) rather than lake-wide object versioning; native lakehouse features may be simpler and have lower operational overhead. 2. Datasets are small and local-first (tens of GB to low TB with manageable file counts); DVC or simpler Git-LFS-style workflows may be easier to operate. 3. The organization cannot operate another stateful service and does not use the managed offering; self-hosting lakeFS introduces operational overhead. 4. Independent, verifiable compliance artifacts are required up front (for example, a SOC 2 Type II report or ISO certifications) and the vendor cannot provide them under NDA or publicly. 5. The primary requirement is end-to-end pipeline orchestration plus lineage packaged together; an orchestration-first stack may be a better single-system approach. 6. Budget transparency is critical and the procurement process requires publicly listed Enterprise pricing; lakeFS Enterprise pricing is provided via sales engagement.

Deal disqualifiers (poor fit)

Small datasets and purely local workflows.
Organization requires only table-level versioning and already has mature Delta/Iceberg governance.
No capacity to operate additional control-plane infrastructure and no willingness to use a managed cloud offering.

Publicly discussed limitations / considerations

Security advisory exposure: a reported S3 gateway timestamp validation vulnerability (fixed in 1.75.0) highlights the importance of patching discipline.
Review ecosystem gap: limited independent review volume makes it harder to validate support quality, stability, and real-world TCO without running a proof-of-concept.
Pricing transparency: Enterprise pricing is not publicly listed.

Roadmap / future features

Documentation references a public roadmap on GitHub, but specific roadmap dates and delivery commitments were not evaluated in depth here. Procurement teams should review roadmap items relevant to their environment (for example, integrations with Iceberg catalogs, governance features, metadata search) and request delivery commitments where necessary.

Why customers might leave or not adopt

Because structured churn reviews are scarce, typical non-adoption drivers are inferred from product architecture and community comments: - Teams standardized on table-format time travel (Delta/Iceberg) may find lakeFS redundant if only table-level rollback is required. - Teams needing a simple local UX for small datasets may prefer DVC or Git-LFS-style workflows. - Enterprises with strict compliance requirements may require clearer publicly available certification evidence or enterprise controls.

02Why they buy

Unique selling points supported by available evidence

Metadata-only branching (zero-copy branching) is a central design principle of lakeFS, described in documentation.
Compatibility with object storage via S3-style interfaces and broad ecosystem integrations is a core design objective.
A scale-focused architecture aiming to support very large object counts is repeatedly referenced in product materials.

Where competitors have clear advantages

DVC: simplicity and strong fit for Git-centric, local workflows.
Table formats (Delta/Iceberg): native table-level time travel and ACID semantics when the environment is table-centric.
Pachyderm: integrated pipelines and provenance for teams wanting an all-in-one platform.

03Field reports

Availability of structured reviews (G2/Capterra/TrustRadius)

A key observation: lakeFS has limited presence on some major B2B review platforms compared with more mainstream data infrastructure products. - G2: No clearly discoverable lakeFS product page with substantial review volume was identified in the conducted searches. - Capterra: No clear lakeFS review listing was found in the reviewed sources. - TrustRadius: A pricing entry exists that conflicts with vendor materials regarding available plans and trials, suggesting review-platform data may be incomplete. - AWS Marketplace: lakeFS Cloud listing showed few or no reviews at the time of capture. Implication: Most customer feedback is currently found in community threads, GitHub issues, and vendor case studies/testimonials rather than large volumes of independently curated review pages.

Representative quotes and sentiment (vendor testimonials)

Vendor materials include testimonials that describe rapid setup, operational improvements, and increased development velocity. These testimonials are marketing-selected; procurement teams should request customer references and validate applicability to the prospective environment.

Community quotes and discussions (forums)

Examples of community sentiment: - A recent community thread comparing lakeFS and DVC included commentary that DVC can be appropriate for smaller file counts while lakeFS is positioned for much larger object counts, and noted that certain advanced features are commercial. What is missing: High-frequency negative user narratives are less visible in short community threads; GitHub issues may provide more detailed operational pain points (see Critical Analysis section).

Why customers choose lakeFS (from sources)

Common reasons cited by vendor materials and community comparisons:

Need for branch-based isolation without full copies of datasets.
Ability to operate at scale (large object counts, multiple teams/pipelines).
Desire for Git-like workflows for data promotion using merges.
Integrations with components of the modern data stack (Spark, Presto/Trino, Airflow, etc.).

Vendor-highlighted case study: a major technology company

Vendor materials highlight a large technology customer as a case study and describe outcomes such as reduced storage costs, improved development velocity, and governance improvements.

Critical evaluation:

Metrics are presented in summary form without detailed measurement methodologies.
It is unclear which improvements are attributable uniquely to lakeFS versus concurrent process or tooling changes.

Vendor-quoted outcomes (examples)

Vendor materials include quotes indicating improved development velocity and reduced testing time in specific deployments.

Critical evaluation:

These outcomes are vendor-published and likely represent favorable examples. Procurement teams should request baseline definitions, measurement windows, sample sizes, and whether results were independently validated.

Mixed/negative case studies

No clear public failed-rollout narratives were identified in the reviewed sources. Vendors rarely publish detailed failure case studies, and public review coverage is limited.

04Best fit

Company size

Typical strong fit appears to be mid-market to enterprise organizations with multi-team data platforms and large object counts.

Industries / verticals

Based on vendor references and public user lists:

Technology and internet companies
Automotive and manufacturing
Aerospace and defense
Public sector and research organizations

Roles and personas

Buyers: Head/VP of Data Engineering, Director of Data Platform, CTO, and security/compliance stakeholders for enterprise deals.
Users: Data engineers, ML engineers, analytics engineers, and platform engineers managing object stores.

Pain points lakeFS addresses

Data incidents requiring rollback.
Non-reproducible ML training data and experiment drift.
Costly development/test dataset duplication.
Need for parallel experimentation on production data within governed promotion workflows.

Qualification criteria (good fit)

Object-storage data lake is a core asset.
Need for branch-based experimentation and governed promotion.
Multiple teams touching shared datasets and pipelines.

05The pitch

What the product does (objective value proposition)

lakeFS is a data version control system for object-storage-based data lakes (for example, Amazon S3, Azure Blob/ADLS, Google Cloud Storage, and other S3-compatible stores). It provides Git-like semantics for data—branching, committing, merging, diffing, and rollback—implemented primarily as a metadata control plane over existing data, intended to enable safer experimentation, reproducible ML training, and production-grade data operations without copying full datasets. In practical terms, teams use lakeFS to: - Create isolated development/test branches of production data with metadata-only branching and copy-on-write behavior. - Run pipeline or model changes on production-scale data without duplicating entire buckets. - Promote validated changes using merges and roll back from data incidents. - Maintain an audit trail and history via commits and references. Official positioning describes the product as a control plane for AI-focused data workflows, emphasizing provenance, governance, and reducing data friction for AI/ML workloads.

Target market and market positioning

Primary audience: data engineering teams, platform teams, MLOps / ML engineering teams operating on large-scale data lakes (high object counts, many pipelines, multi-team collaboration).
Positioning: Git-like version control for data at enterprise/petabyte-scale, differentiating from Git-based or file-based approaches (for example, DVC) that can become difficult to manage at very large object counts.

Get a comprehensive analysis of lakeFS including market position, competitive landscape, adoption trends, and peer benchmarks.

Download full report →

Published Oct 15, 2026

01Common complaints

The organization only needs table-format time travel (for example, within Delta Lake or Iceberg tables) rather than lake-wide object versioning; native lakehouse features may be simpler and have lower operational overhead.
Datasets are small and local-first (tens of GB to low TB with manageable file counts); DVC or simpler Git-LFS-style workflows may be easier to operate.
The organization cannot operate another stateful service and does not use the managed offering; self-hosting lakeFS introduces operational overhead.
Independent, verifiable compliance artifacts are required up front (for example, a SOC 2 Type II report or ISO certifications) and the vendor cannot provide them under NDA or publicly.
The primary requirement is end-to-end pipeline orchestration plus lineage packaged together; an orchestration-first stack may be a better single-system approach.
Budget transparency is critical and the procurement process requires publicly listed Enterprise pricing; lakeFS Enterprise pricing is provided via sales engagement.

Deal disqualifiers (poor fit)

Small datasets and purely local workflows.
Organization requires only table-level versioning and already has mature Delta/Iceberg governance.
No capacity to operate additional control-plane infrastructure and no willingness to use a managed cloud offering.

Publicly discussed limitations / considerations

Security advisory exposure: a reported S3 gateway timestamp validation vulnerability (fixed in 1.75.0) highlights the importance of patching discipline.
Review ecosystem gap: limited independent review volume makes it harder to validate support quality, stability, and real-world TCO without running a proof-of-concept.
Pricing transparency: Enterprise pricing is not publicly listed.

Roadmap / future features

Why customers might leave or not adopt

Because structured churn reviews are scarce, typical non-adoption drivers are inferred from product architecture and community comments:

Teams standardized on table-format time travel (Delta/Iceberg) may find lakeFS redundant if only table-level rollback is required.
Teams needing a simple local UX for small datasets may prefer DVC or Git-LFS-style workflows.
Enterprises with strict compliance requirements may require clearer publicly available certification evidence or enterprise controls.

02Why they buy

Unique selling points supported by available evidence

Metadata-only branching (zero-copy branching) is a central design principle of lakeFS, described in documentation.
Compatibility with object storage via S3-style interfaces and broad ecosystem integrations is a core design objective.
A scale-focused architecture aiming to support very large object counts is repeatedly referenced in product materials.

Where competitors have clear advantages

DVC: simplicity and strong fit for Git-centric, local workflows.
Table formats (Delta/Iceberg): native table-level time travel and ACID semantics when the environment is table-centric.
Pachyderm: integrated pipelines and provenance for teams wanting an all-in-one platform.

03Field reports

Availability of structured reviews (G2/Capterra/TrustRadius)

A key observation: lakeFS has limited presence on some major B2B review platforms compared with more mainstream data infrastructure products.

G2: No clearly discoverable lakeFS product page with substantial review volume was identified in the conducted searches.
Capterra: No clear lakeFS review listing was found in the reviewed sources.
TrustRadius: A pricing entry exists that conflicts with vendor materials regarding available plans and trials, suggesting review-platform data may be incomplete.
AWS Marketplace: lakeFS Cloud listing showed few or no reviews at the time of capture.

Implication: Most customer feedback is currently found in community threads, GitHub issues, and vendor case studies/testimonials rather than large volumes of independently curated review pages.

Representative quotes and sentiment (vendor testimonials)

Community quotes and discussions (forums)

Examples of community sentiment:

A recent community thread comparing lakeFS and DVC included commentary that DVC can be appropriate for smaller file counts while lakeFS is positioned for much larger object counts, and noted that certain advanced features are commercial.

What is missing: High-frequency negative user narratives are less visible in short community threads; GitHub issues may provide more detailed operational pain points (see Critical Analysis section).

Why customers choose lakeFS (from sources)

Common reasons cited by vendor materials and community comparisons:

Need for branch-based isolation without full copies of datasets.
Ability to operate at scale (large object counts, multiple teams/pipelines).
Desire for Git-like workflows for data promotion using merges.
Integrations with components of the modern data stack (Spark, Presto/Trino, Airflow, etc.).

Vendor-highlighted case study: a major technology company

Vendor materials highlight a large technology customer as a case study and describe outcomes such as reduced storage costs, improved development velocity, and governance improvements.

Critical evaluation:

Metrics are presented in summary form without detailed measurement methodologies.
It is unclear which improvements are attributable uniquely to lakeFS versus concurrent process or tooling changes.

Vendor-quoted outcomes (examples)

Vendor materials include quotes indicating improved development velocity and reduced testing time in specific deployments.

Critical evaluation:

These outcomes are vendor-published and likely represent favorable examples. Procurement teams should request baseline definitions, measurement windows, sample sizes, and whether results were independently validated.

Mixed/negative case studies

No clear public failed-rollout narratives were identified in the reviewed sources. Vendors rarely publish detailed failure case studies, and public review coverage is limited.

04Best fit

Company size

Typical strong fit appears to be mid-market to enterprise organizations with multi-team data platforms and large object counts.

Industries / verticals

Based on vendor references and public user lists:

Technology and internet companies
Automotive and manufacturing
Aerospace and defense
Public sector and research organizations

Roles and personas

Buyers: Head/VP of Data Engineering, Director of Data Platform, CTO, and security/compliance stakeholders for enterprise deals.
Users: Data engineers, ML engineers, analytics engineers, and platform engineers managing object stores.

Pain points lakeFS addresses

Data incidents requiring rollback.
Non-reproducible ML training data and experiment drift.
Costly development/test dataset duplication.
Need for parallel experimentation on production data within governed promotion workflows.

Qualification criteria (good fit)

Object-storage data lake is a core asset.
Need for branch-based experimentation and governed promotion.
Multiple teams touching shared datasets and pipelines.

05The pitch

What the product does (objective value proposition)

In practical terms, teams use lakeFS to:

Create isolated development/test branches of production data with metadata-only branching and copy-on-write behavior.
Run pipeline or model changes on production-scale data without duplicating entire buckets.
Promote validated changes using merges and roll back from data incidents.
Maintain an audit trail and history via commits and references.

Official positioning describes the product as a control plane for AI-focused data workflows, emphasizing provenance, governance, and reducing data friction for AI/ML workloads.

Target market and market positioning

Primary audience: data engineering teams, platform teams, MLOps / ML engineering teams operating on large-scale data lakes (high object counts, many pipelines, multi-team collaboration).
Positioning: Git-like version control for data at enterprise/petabyte-scale, differentiating from Git-based or file-based approaches (for example, DVC) that can become difficult to manage at very large object counts.

Get a comprehensive analysis of lakeFS including market position, competitive landscape, adoption trends, and peer benchmarks.

Download full report →