cloudparts

PravegaArchived

A stream storage service from Dell that kept events in Apache BookKeeper and moved them to long-term storage, with streams that split and merge their segments automatically as load changes; archived by the CNCF in 2025.

CNCF · Archived
What it is
Event streams
Type
Open source
Made by
Pravega Authors (started at Dell)
Foundation
Cloud Native Computing Foundation, archived, joined November 2020. Part of the Linux Foundation
License
Apache 2.0
Status
Archived since 23 September 2025
Facts checked
24 October 2026

What it is

Pravega stores streams: durable, append-only, unbounded sequences of events, grouped into scopes. Each stream is split into segments, and each event carries a routing key that decides its segment, so events with the same key are read in the order they were written. Unlike a Kafka topic, the number of segments isn’t fixed: under a data- or event-rate scaling policy a hot segment splits in two and cold neighbours merge, and readers in a reader group are rebalanced across the new segments. Writers can batch events in transactions that become visible only on commit, and readers persist their positions, so applications such as Flink jobs can process each event exactly once. A state synchronizer lets distributed processes share state through a stream with optimistic, conditional updates.

Two kinds of server do the work. A controller, the control plane, creates, scales and deletes streams. The segment store, the data plane, writes incoming events first to Tier 1 storage, built on Apache BookKeeper, for low-latency durability, and later moves them to Tier 2 long-term storage such as HDFS, a file system or an object store, from which old data can still be read through the same stream API. The project was written in Java, licensed under Apache 2.0 and released 0.13.0, its last version, in September 2023.

Why teams pick it

  • Streams scale their segments up and down automatically with load, without a fixed partition count
  • One API covers both fresh events in BookKeeper and old data in long-term storage, so streams can be kept indefinitely
  • Per-key ordering, transactions and exactly-once reading built into the client
  • Apache 2.0 code that can still be studied as a design for elastic, tiered stream storage

Watch out for

  • Archived: no releases since September 2023, no commits since March 2025, and no maintainers for the core
  • Never reached 1.0, and its clients (Java, plus Rust, Python, Node.js and C#) and Flink and Spark connectors are a far smaller ecosystem than Kafka’s or Pulsar’s
  • Running it meant a controller, a segment store, BookKeeper, ZooKeeper and a long-term store

Alternatives, recommended first

What all event streams have in common →Compare side by side →

How it fits with other technologies

See it in a real stack

No architecture uses Pravega yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2016–2025

Dell engineers started Pravega in 2016 to give streaming data a storage primitive like a file or an object: unbounded, durable, strictly ordered, and elastic enough to follow changing load without anyone resizing partitions. They built it on Apache BookKeeper for the hot tail of each stream and on Dell’s own Isilon and ECS storage, or HDFS, for the long tail, and released 0.1.0 under Apache 2.0 in September 2017.

Pravega joined the CNCF Sandbox in November 2020. In March 2024 work on it dropped sharply after the main contributing organisation changed priorities, and in June 2025 the CNCF heard that the original team had been disbanded. A maintainer argued that two EU research projects, NEARDATA and CLOUDSKIN, still used it, but with no core development for over a year the TOC voted to archive it, and it was archived on 23 September 2025, free to reapply if active development resumes.

Why it’s built this way

Segments that split and merge
Fixed partition counts force users to guess future load; letting segments scale with event or byte rate keeps per-key order while the stream grows and shrinks.
Two storage tiers behind one API
BookKeeper gives low-latency durable writes but is costly for years of data; moving segments to HDFS or object storage keeps history cheap while readers see one continuous stream.
Exactly-once in the client
Stream processors like Flink need reader positions and transactional writes they can checkpoint, so Pravega built both into its client API.

Timeline

  1. 2016

    Development starts at Dell; repository created in July

  2. 2017

    0.1.0, the first release, in September

  3. 2020

    Accepted into the CNCF Sandbox on 10 November

  4. 2023

    0.13.0, the last release, in September

  5. 2024

    Core development drops off in March

  6. 2025

    Last commit in March; CNCF archives the project on 23 September

Sources6 · facts checked 24 October 2026

Improve this page on GitHub