Venice: LinkedIn's derived data platform for feature store workloads

Five characteristics, and the reason a feature store needs them

Venice is described as a derived data storage platform with five named characteristics. High throughput asynchronous ingestion from batch and streaming sources, with Hadoop and Samza given as examples. Low latency online reads via remote queries or in-process caching. Active-active replication between regions with CRDT-based conflict resolution. Multi-cluster support within each region with operator-driven cluster assignment. And multi-tenancy, horizontal scalability and elasticity within each cluster. Those five together explain why it exists rather than a general-purpose database. A feature store such as Feathr is the named use case, where AI applications feed the output of their ML training jobs into Venice and then query the data during online inference. The system straddles the offline, nearline and online worlds, and the architecture diagram in the repository is titled accordingly. The distinguishing claim is that one store serves all three, rather than a lake feeding a cache that a serving tier reads from.

The dependency is not on Maven Central, and that is the first hurdle

Venice is a Java project and the README is explicit that Venice dependencies are not published on Maven Central, so an extra repository definition is required. The published jars are visible in the LinkedIn JFrog UI, and the project is usually released a few times per week, which means the version you pin will be superseded quickly. For Gradle the repository block and the dependency go together.

repositories {
  mavenCentral()
  maven {
    name 'VeniceJFrog'
    url 'https://linkedin.jfrog.io/artifactory/venice'
  }
}

dependencies {
  implementation 'com.linkedin.venice:venice-client:0.4.455'
}

The Maven route adds the same repository as a repository element with the id venice-jfrog and pulls the venice-client artifact at the same version. The group id is com.linkedin.venice and the artifact is venice-client, with the scope set to compile in the XML example. A weekly release cadence and a private artifact repository is a reasonable arrangement for an internal platform, but it does mean a consumer outside LinkedIn is depending on a repository whose availability is not their to control.

Write paths: batch, incremental, streaming and compute

Venice supports flexible data ingestion across five modes. Batch push replaces a full dataset, coming from Hadoop or Spark. Incremental push adds to what is there without replacing it. Streaming writes give real-time updates through Apache Samza or the Online Producer client, which is a separate write API documented in the user guide. Write compute performs partial updates and merges collections, which the README frames as an efficiency measure. And hybrid stores mix batch and streaming with a configurable rewind time. That last mode is the interesting one for a feature store, because a model trained on a snapshot and a feature served from a live stream are rarely the same thing, and a rewind window lets one store serve both without a second copy. The write modes are decoupled from the read side, so the choice of write API does not constrain which read API you can use later.

Read paths and three client tiers with different latency

The read side offers single get, batch get, and read compute with server-side operations such as dot product, cosine similarity and field projection. The read compute option is what makes this more than a key-value store for machine learning use, because the expensive part of an online inference request can happen before the data leaves the server. The client types are where the latency numbers come from. The thin client is stateless with two network hops and under 10ms latency. The fast client is partition-aware with one network hop and under 2ms. The Da Vinci client is a stateful local cache with zero network hops and under 1ms. All three share the same APIs, which the README presents as the point: you can move a workload between tiers without changing code, and trade cost against performance. The catch is that the figures are per tier, and the best one depends on having a client close to the data.

Change data capture, and why it matters to a model serving path

Change Data Capture streams all data changes, meaning inserts, updates and deletes, for use cases like ML feature retrieval and client-side indexing. For a feature store this is load-bearing. A model that scores against features needs to know when a feature has been corrected or removed, not only that a new value arrived, because a stale value is silently wrong in a way that a missing value is not. Emitting the delete and update stream separately from the append path means the consumer can maintain its own view, which is the same thing the Da Vinci client cache is doing locally. The README also points to an architecture overview document in the getting started section for a fuller guide to the architecture, write modes, client characteristics and capabilities, and a getting started index that covers both single and multi-datacenter deployments.

A Java and Gradle monorepo with services, clients and tests

The repository layout shows the scale of the project. There is an all-modules directory, a clients directory, a docker directory for running things locally, a docs directory, an integrations directory, an internal directory, a services directory holding the server-side components, a specs directory, a tests directory, and a scripts directory, alongside a build.gradle, a settings.gradle, a gradle.properties and the Gradle wrapper. The presence of separate services, clients and internal modules, with a specs directory for the interfaces between them, is the structure you would expect from a system where the read path and the write path are genuinely separate pieces of infrastructure. The docs are built with mkdocs, and the make_tag.py script sits at the root for release tagging, which fits the weekly release cadence the README describes. The licence is BSD-2-Clause, the repository is not archived, and the last push was on 2026-10-20, so the tree is actively maintained even though there are no GitHub release tags to point at.

Editorial conclusion

Venice fits a machine learning platform team that needs one store to hold both the output of training jobs and the reads that serve online inference, and that is prepared to run a stateful storage system rather than bolt one onto an existing key-value store. It does not fit a small team that wants a managed service, since the dependencies are published to a LinkedIn JFrog repository rather than Maven Central and the project is Java-only. Verify first that your team can run the services, add the Venice JFrog repository to your build before you try to resolve the client artifact, and read the client tiers carefully, because the latency figures quoted in the README only hold for the client you choose.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-2-Clause
3. linkedin/venice on GitHub
4. Project website
5. README