PHphilips·Dec 15, 2018
Woah! I would love to get this testimonial in our production users doc!
https://github.com/etcd-io/etcd/blob/master/Documentation/pr...
In Red Hat contributes etcd to the Cloud Native Computing Foundationetcd-io
etcd
Go2013–2024
etcd-io / etcd
etcd
Distributed reliable key-value store for the most critical data of a distributed system
79Distinct people
108Mentions
0Explicit recommenders
52.6KGitHub stars
What to know before exploring
What it is
Distributed reliable key-value store for the most critical data of a distributed system
GitHub
Where it is used
- Fidelity Investments — “We use CoreDNS for service discovery, etcd as KV store, Fluentd for logging, Helm as a package manager, Kubernetes for container orchestration, rely on CNI …” Source
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- hashicorp/consul · linked in 2 of the same discussions
- influxdata/influxdb · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 9:28:18 AM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year108 dated mentions
Observed mentions: 2013-07-31 15:48:56 UTC to 2024-11-28 01:23:10 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 11 | 2 | 9 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 13 | 0 | 13 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 20 | 2 | 18 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 15 | 0 | 15 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 12 | 0 | 12 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 6 | 1 | 5 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 4 | 2 | 2 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 7 | 0 | 7 |
What Hacker News says
8 sourcesetcd has succeeded as a piece of distributed systems infrastructure beyond our wildest expectation. When Alex Polvi, Xiang Li, and I started the project as a README in the summer of 2013 we identified that their still was no consensus database that was developer friendly, easily secured, production ready, and based on a well understood consensus algorithm. And largely we got lucky with good market timing, the invention of the Raft algorithm, and the explosion of good tooling around the Go language. This lead to early success as etcd was used in locksmith, skydns, and vulcan load balancer.
As the years went on we got lucky again that the Kubernetes project chose etcd as its primary key-value database. This helped to establish the project as a must use piece of infrastructure software. Which went on to influence the technology selection of
Read the rest
storage, database, networking, and many other projects. Just check out all of the stickers of projects relying on etcd that I could find at KubeCon here in Seattle. https://twitter.com/BrandonPhilips/status/107370136987218739...
For a sense of all of the projects that use checkout this list we maintain in the project: https://github.com/etcd-io/etcd/blob/master/Documentation/in...
Some notable projects include: Kubernetes, Rook, CoreDNS, Uber M3, Trillian, Vitess, TiDB, and many many others.
Moving into the CNCF will help to bring a few things to the project:
- Funding and resources to complete regular third-party security audits and correctness audits
- On-call rotation and team for the discovery.etcd.io system
- Assistance in maintaining a documentation website
- Resources to fund face to face meetup groups and maintainer meetings
As a closing remark I want to thank the over 450 contributors and the entire maintainer team for bringing the project to this point. We are solving an important distributed systems problem with a focused piece of technology.
In fact, in Seattle this week we all got together as a maintainer team for the first time ever: https://twitter.com/sp_zala/status/1073239003330015233
If you want to learn more about the history of the project checkout this other post blog post: https://coreos.com/blog/history-etcd
if err != nil
return err
if err != nil
return err
if err != nil
return err
https://github.com/docker/cli/search?q=%22if+err+%21%3D+nil%...
https://github.com/kubernetes/kubernetes/search?q=%22if+err+...
https://github.com/coreos/etcd/search?q=%22return+err%22&uns...
https://github.com/influxdata/influxdb/search?q=%22if+err+%2...
The reality of Go's error handling is that you just implement exactly what exception bubbling does painfully by hand.
In Exploring Error Handling Patterns in GoThat is the process: https://github.com/coreos/etcd/blob/master/Documentation/upg...
for i in members
Replace etcd binary
Restart etcd process
In The Horrors of Upgrading Etcd Beneath KubernetesHey thanks for the article. I know etcd upgrades can look complex but upgrading distributed databases live is always going to be quite non-trivial.
That said for many people taking some downtime on their Kube API server isn't the end of the world. The system, by design, can work OK for sometime in a degraded state: workloads keep running.
A few things that I do want to try to clarify:
1) The strict documented upgrade path for etcd is because testing matrixes just get too complicated. There aren't really technical limitations as much as wanting to ensure recommendations are made based on things that have been tested. The documentation is all here: https://github.com/coreos/etcd/tree/master/Documentation/upg...
2) Live etcd v2 API -> etcd v3 API migration for Kubernetes was never a priority for the etcd team at CoreOS because we never shipp
Read the rest
ed a supported product that used Kube + etcd v2. Several community members volunteered to make it better but it never really came together. We feel bad about the mess but it is a consequence of not having that itch to scratch as they say.
3) Several contributors, notably Joe Betz of Google, have been working to keep older minor versions of etcd patched. For example 3.1.17 was released 30 days ago and the first release of 3.1 was 1.5 years ago. These longer lived branches intend to be bug fix only.
Not an etcd user but my first question was why they chose some new (and now unmaintained) golang key value store as their database instead of something more widely used (sqlite or bdb seem like the obvious alternatives). I was able to find this analysis they did in 2015: https://github.com/coreos/etcd/issues/2646 .
On the face of it, it feels like using a more established an well tested database would have been a better choice, even with the facts available to them at the time. Personally I would have been really reluctant to adopt a database whose first commit was in the previous year with only one major contributor. Three years later, they've had to adopt the database code after it was abandoned by the original maintainer.
In Etcd 3.3 – Improvements to stability, performance, and moreThe replacement machine will start pulling its data from the remaining nodes when it joins the cluster. However, it's recommended to migrate the failed node's data first if it's greater than 50MB: https://github.com/coreos/etcd/blob/master/Documentation/op-...
In Scaling Kubernetes to 2,500 Nodes