etcd-io

etcd

Go2013–2024

etcd-io / etcd

etcd

Distributed reliable key-value store for the most critical data of a distributed system

Explore on GitHub Read Hacker News discussions

79Distinct people

108Mentions

0Explicit recommenders

52.6KGitHub stars

REPOSITORY AT A GLANCE

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, 4:01:40 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

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
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

15 sources

slap_shot·Dec 28, 2016

Great read. Did you look at etcd[0][1] when considering a distributed kv store/locking mechanism? If so, what were the pros/cons of each and what lead you to consul? [0] https://github.com/coreos/etcd [1] https://github.com/coreos/etcd/tree/master/client

In Distributed Locks with Consul and Golang

mugsie·Dec 6, 2016

The great thing about open source is that you can make changes when you see some thing that is wrong :) https://github.com/coreos/etcd/blob/master/Documentation/v2/... and https://github.com/coreos/etcd/blob/master/Documentation/op-... are the two pages.

In Show HN: konfd – Manage Kubernetes secrets and configmaps with Go templates

SEJeff·Dec 1, 2016

Can you please please please use the etcd implementation[1] of raft and not the normal go-raft or consul raft implementations? They've done some serious business fault injection and integration testing with etcd as part of google's hosted kubernetes (GKE). There are still some lingering issues with consul at scale that make me a bit gunshy. Mesosphere did some of this work themselves: https://mesosphere.com/blog/2015/10/26/etcd-mesos-kubernetes... , but I know that Google engineers have done tons of work on this as well. [1] https://github.com/coreos/etcd/tree/master/contrib/raftexamp...

In Tank – A very high performance distributed log service

otoolep·Jul 19, 2016

Best? I don't know. The etcd implementation is pretty well known too: https://github.com/coreos/etcd/tree/master/raft I'm just more familiar with the one from Hashicorp, and it's used in a few production systems.

In Show HN: A reference use of Hashicorp's Raft implementation

Perceptes·Jul 1, 2016

Seems worth noting as well that this only upgrades the version of the cluster. Data populated via the v2 API will not magically be available via the v3 API as they have separate data stores/keyspaces. https://github.com/coreos/etcd/blob/v3.0.0/Documentation/op-... talks about how to migrate data that was stored with v2 to v3's data store.

In Etcd v3: increased scale and new APIs

ideal0227·Jul 1, 2016

We are working on it (https://github.com/coreos/etcd/issues/5067). Probably we could work together on the Java client first? It should not be hard given that gRPC supports Java.

In Etcd v3: increased scale and new APIs

ideal0227·Jul 1, 2016

Yes. Here: https://godoc.org/github.com/coreos/etcd/clientv3/concurrenc... It would be great if you can provide opinions, comments or help on these high level APIs. We also might move these to an internal proxy layer, so that other clients in other language can use it more easily. (some more here: https://github.com/coreos/etcd/tree/master/contrib/recipes)

In Etcd v3: increased scale and new APIs

philips·Jul 1, 2016

Great question. The upgrade path is a rolling upgrade from v2.3.y series to v3.0.0 series. This is how all of the etcd upgrades have worked since the start of v2.x.y. Doc is here: https://github.com/coreos/etcd/blob/master/Documentation/upg...

In Etcd v3: increased scale and new APIs

Perceptes·Jul 1, 2016

It's not mentioned in the blog post—is there a document that explains the migration plan for the etcd that ships on the host in CoreOS? Edit: They haven't been published to the docs on the CoreOS website yet, but there are two documents listed under "upgrading and compatibility" at the bottom of https://github.com/coreos/etcd/blob/v3.0.0/Documentation/doc...

In Etcd v3: increased scale and new APIs

ideal0227·Jun 30, 2016

Consul: https://github.com/hashicorp/consul/blob/master/bench/result... etcd: https://github.com/coreos/etcd/blob/master/Documentation/op-... Note that the testing environments are not exact the same in the doc I listed, but comparable. Also Consul performance is improved after a few releases. So we did the benchmark internally on the same environment. The result is still comparable to what I listed in the two official docs. The best way to compare performance is still probably to run the benchmark on your own environment.

In Etcd v3: increased scale and new APIs

emirozer·Jun 30, 2016

It's based on Raft : https://github.com/coreos/etcd/tree/master/raft https://raft.github.io/

In Etcd v3: increased scale and new APIs

rgacote·Apr 14, 2016

etcd (https://github.com/coreos/etcd) or one of its variants is an option.

In Ask HN: Where to store sensitive keys?

maleck13·Mar 30, 2016

Can you explain further why golang is bad for data stores, do you mean cache in particular? Seems contrary to many of the new datastores that I see being developed: etcd[1] , cockroachdb[2], influxdb[3] just to name a couple that are written in go. [1]https://github.com/coreos/etcd [2]https://github.com/cockroachdb/cockroach [3]https://github.com/influxdata/influxdb

In Writing a very fast cache service with millions of entries in Go

conorgil145·Mar 9, 2016

There are many ways to accomplish an external configuration. I do not know how they do it at Netflix, but one could have the prebaked AMI reach out to a service discovery tool to pull its configuration at run time. For example, Consul [1] or etcd [2]. One advantage of this approach is that you can use the exact same AMI in testing as in production. All you would have to do is change the configuration which is pulled. You could determine which configuration to pull based on AWS tags on the EC2 instance, for example. [1] https://www.consul.io/ [2] https://github.com/coreos/etcd

In How We Build Code at Netflix

philips·Feb 27, 2016

Here is a similar project built on the etcd raft package: https://github.com/chzchzchz/raftsql The etcd raft package is used by CockroachDB and etcd. The godoc is over here: https://godoc.org/github.com/coreos/etcd/raft

In Rqlite: Replicated SQLite using the Raft consensus protocol

REPOSITORY NOTES

Stars

52,476

Forks

10,568

Top contributors by commits

gyuho4,387 commits
ahrtr2,323 commits
xiang902,040 commits
serathius1,908 commits
yichengq1,451 commits

GitHub contributors

Description source

GitHub

Language

License

Apache-2.0

First mentioned

Jul 31, 2013

Last mentioned

Nov 28, 2024

Status

Not archived

Project website

GitHub details last checked: November 12, 2026 at 21:52 PST.

Last code push on GitHub: November 12, 2026 at 09:17 PST.

Update overdue. The displayed GitHub details are awaiting a refresh.

HN discussion data updated through: November 2, 2026 at 00:16 PST.

Where it’s used

Fidelity Investments

Production case study · Source published 2021-03-04

“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 …”

CNCF case study