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 →
RedpandaCommercialA Kafka-compatible streaming broker rewritten in C++ as one binary, with no JVM and no ZooKeeper.Apache BookKeeperOpen sourceA replicated log storage service from Yahoo!: clients append entries to ledgers that are striped and copied across storage servers called bookies, with metadata in ZooKeeper. Apache Pulsar keeps its messages in it.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
- 2016
Development starts at Dell; repository created in July
- 2017
0.1.0, the first release, in September
- 2020
Accepted into the CNCF Sandbox on 10 November
- 2023
0.13.0, the last release, in September
- 2024
Core development drops off in March
- 2025
Last commit in March; CNCF archives the project on 23 September
- GitHub: pravega/pravega NOTICE (Copyright 2017–2021 Dell Inc.; contains code from Apache BookKeeper)
- GitHub: pravega/pravega releases (0.1.0 September 2017, 0.13.0 September 2023)
- CNCF landscape: Pravega (accepted 10 November 2020, archived 23 September 2025)
- GitHub: pravega/pravega issue #7436, [CNCF TOC] Archive Pravega Project (October 2024)
- GitHub: cncf/toc issue #1460, [HEALTH] Pravega (archive vote passed September 2025)
Sources6 · facts checked 24 October 2026
- Pravega docs: Concepts (streams, segments, auto scaling, routing keys, transactions, Tier 1 BookKeeper, Tier 2, controller, segment store)
- GitHub: pravega/pravega README (Apache 2.0, Java)
- GitHub: pravega/pravega commits (last commit March 2025)
- GitHub: pravega organisation repositories (Flink and Spark connectors; Rust, Python, Node.js and C# clients)
- GitHub: cncf/toc issue #1460 (archived after TOC vote)
- CNCF: Pravega project page