The Generational Shift in Data Stores and Queues — Licenses, Forks and the Apache Attic

Introduction — in this layer the terms change before the code does
1. Redis
2. Elasticsearch and Kibana
3. MongoDB
4. Kafka's ZooKeeper dependency
5. Apache Sqoop
6. Apache Oozie
7. Apache Giraph
8. Apache Tajo
9. RethinkDB
10. PrestoSQL — the case where the name changed
Conclusion — three signals to watch in the data layer
Related reading
Series

Introduction — in this layer the terms change before the code does

Data stores carry the highest replacement cost of any layer. That is exactly why movement here is driven more often by changes in distribution terms than by technical merit. Licenses change, forks appear, foundations change hands.

Every entry below rests on dated facts only: official announcements, repository state, Apache Attic records. For license changes I state who moved what from where to where, and do not speculate about motive.

1. Redis

What it was — an in-memory data store distributed under BSD 3-Clause.
Why it was right at the time — it still is. This is a case of distribution terms changing, not technology.
What changed — an announcement on 20 March 2024 moved Redis from BSD 3-Clause to dual RSALv2 and SSPLv1 licensing beginning with Redis 7.4. The same post explicitly acknowledges that this means Redis is no longer open source under the OSI definition, and states that the change is not retroactive. Later, an announcement on 1 May 2025 added the OSI-approved AGPLv3 as an option starting with Redis 8.
What took its place — Valkey, presented as a BSD-licensed high-performance key/value datastore and stewarded by the Linux Foundation.
What it left behind — the Redis protocol and data-structure model became an effective industry interface. That every fork preserves it is the proof.
When it is still right — for most users. Since the 2025 announcement, AGPLv3 is available, so organisations that require an OSI license can satisfy that requirement.

2. Elasticsearch and Kibana

What it was — a search and analytics engine and its visualisation tool, distributed under Apache 2.0.
Why it was right at the time — it provided the standard way to operate inverted-index search in a distributed fashion.
What changed — Elastic moved to dual SSPL and Elastic License terms from 7.11 in an announcement on 14 January 2021. Later, an announcement on 29 August 2024 added AGPL as an option, stating that this adds an option rather than removing anything.
What took its place — OpenSearch. The fork was announced in January 2021, 1.0 shipped under Apache 2.0 that July, and the project later moved to the OpenSearch Software Foundation under the Linux Foundation.
What it left behind — the query DSL and index operations practices persist on both branches, making them an effective common interface.
When it is still right — for most users. With the AGPL option the license question is largely resolved. Organisations whose procurement requires vendor neutrality may prefer the fork.

3. MongoDB

What it was — a document database distributed under AGPL v3.
Why it was right at the time — there was a period when schema flexibility was the actual requirement, and this was the product that served it best.
What changed — per the official FAQ, releases on or after 16 October 2018 moved to the SSPL. The SSPL requires that if you make the program available to third parties as a service, you make the service source code available; that clause does not apply to internal-only use.
What took its place — no dominant fork formed in this case. Instead, document-type support in relational databases became the alternative.
What it left behind — the SSPL itself. Other projects subsequently adopted the same license, which turned it into a trend.
When it is still right — for internal use there is no issue under the FAQ. Only if you intend to offer a managed service to third parties do you need to read the clause.

4. Kafka's ZooKeeper dependency

What it was — a separate consensus system Kafka ran alongside itself to store broker lists and partition metadata.
Why it was right at the time — borrowing a proven consensus implementation instead of writing one was a reasonable initial design decision.
What changed — the Kafka 4.0.0 release announcement, dated 18 March 2025, states that 4.0 is the first major release to operate entirely without Apache ZooKeeper. KRaft mode is the default.
What took its place — KRaft. The metadata quorum moved inside the Kafka brokers.
What it left behind — what ZooKeeper proved is the category of a consensus-based coordination service. Many systems grew while depending on that category, and a number of them later moved to their own implementations. The ZooKeeper project itself continues to exist.
When it is still right — if you run Kafka 3.x there is no rush. The migration simply becomes mandatory when you move to 4.0.

5. Apache Sqoop

What it was — a bulk data transfer tool between relational databases and Hadoop.
Why it was right at the time — moving whole tables inside a batch window was real work, and this parallelised it.
What changed — per the Attic record, it became a Top Level Project in March 2012, retired in June 2021, and completed the move to the Attic in July 2021.
What took its place — Spark and Flink based ingestion jobs, and change-data-capture pipelines.
What it left behind — the approach of reading the schema to decide parallel splits automatically. Modern ingestion tools solve the same problem the same way.
When it is still right — only to keep an existing batch running. Attic projects produce no new releases.

6. Apache Oozie

What it was — a workflow scheduler for Hadoop jobs.
Why it was right at the time — expressing dependencies between jobs declaratively and attaching retries and time-based execution is the archetype of today's workflow tooling.
What changed — per the Attic record, it became a Top Level Project in August 2012, retired in February 2025, and completed the move in April 2025.
What took its place — code-driven workflow orchestrators such as Airflow.
What it left behind — the model of expressing batches as a directed acyclic graph. XML became Python; the structure is the same.
When it is still right — only to maintain existing workflows.

7. Apache Giraph

What it was — a system for large-scale iterative graph processing.
Why it was right at the time — the vertex-centric programming model pushed social graph computation to billions of edges.
What changed — per the Attic record, it became a Top Level Project in May 2012, retired in September 2023, and completed the move in February 2024.
What took its place — graph libraries on general-purpose distributed engines, and dedicated graph databases.
What it left behind — the vertex-centric computation model and the superstep concept, adopted directly by later frameworks.
When it is still right — never.

8. Apache Tajo

What it was — a data warehouse system running on Hadoop.
Why it was right at the time — executing distributed SQL directly rather than going through a batch engine is the direction the whole industry later took.
What changed — per the Attic record, it became a Top Level Project in March 2014, retired in September 2020, and completed the move in April 2021.
What took its place — the Trino and Spark SQL families, and cloud warehouses.
What it left behind — confirmation that the distributed SQL engine category was the right one, and a record of a Korean developer community leading an Apache Top Level Project.
When it is still right — never.

9. RethinkDB

What it was — a document database that offered real-time change subscriptions as a first-class feature.
Why it was right at the time — the idea that an application subscribes to changes in a query result was ahead of its time.
What changed — per the announcement of 6 February 2017, the company shut down, but the CNCF purchased the source code rights and contributed them to the Linux Foundation, with the code redistributed under the permissive Apache 2.0 license. The same post states that the project is alive and that development can continue without disruption.
What took its place — mainstream databases offering change streams, and backend services offering real-time sync.
What it left behind — the change-subscription feature category, plus a precedent that code and community can continue through a foundation even when the company closes.
When it is still right — systems already in production. For something new there are far more alternatives.

10. PrestoSQL — the case where the name changed

What it was — one branch of a distributed SQL query engine.
Why it was right at the time — it still is. This is a case of a name changing, not technology.
What changed — in an announcement on 27 December 2020, the original developers stated that the project was being renamed Trino. According to the announcement, a trademark issue was the trigger.
What took its place — Trino. The same people continue with the same codebase.
What it left behind — the fact that a project name and its trademark are assets separate from the code, and a case study showing that separation has real operational consequences.
When it is still right — only the name changed, so carry on. You just need to know that both names appear when you search the documentation.

Conclusion — three signals to watch in the data layer

First, the license terms and their history of change. In this layer those terms move people before code quality does. But as Redis and Elastic show, the direction is not one-way: both later restored an OSI-approved license as an option.

Second, foundation affiliation. RethinkDB survived the company's closure through a foundation transfer, and Apache Attic records leave retirement dates as public documents. A project with documented governance at least lets you check its state.

Third, the trend of the core absorbing external dependencies. As Kafka removed ZooKeeper, external dependencies with a heavy operational burden eventually get pulled into the core or stripped out. If you run a separate coordination service today, its roadmap is worth checking.

Status information was verified directly on 2026-08-12. Projects sometimes become active again, so check the current state yourself.