etcd is a free, open source databases project written in Go and released under Apache-2.0. It has 52,270 GitHub stars, 10,504 forks and 351 open issues, and was last pushed 6 hours ago. On this registry it ranks #4 of 81 tracked projects in Databases, with 5 head-to-head comparisons available. It gained 4 stars over the last 3 tracked days.

What is etcd?

etcd is an Apache-2.0 licensed, Go-written distributed key-value store that holds the most critical data of a distributed system in a Raft-replicated log, aimed at the platform and infrastructure engineers who must keep that control-plane data consistent and available.

What it is

etcd is a distributed reliable key-value store for the most critical data of a distributed system. It is written in Go and uses the Raft consensus algorithm to manage a highly-available replicated log, so every member of a cluster converges on the same ordered sequence of writes. The project describes four design commitments: a simple, well-defined user-facing gRPC API; security through automatic TLS with optional client certificate authentication; speed, benchmarked at 10,000 writes per second; and reliability, achieved by proper distribution over Raft. It sits in the CNCF ecosystem, is catalogued under Infrastructure and Operations / Databases, and publishes its documentation at etcd.io.

The concrete problem etcd solves is agreement. Rather than letting each service invent its own coordination layer, the README positions etcd as the shared store behind applications such as Kubernetes, locksmith, vulcand and Doorman, which depend on it for data that must survive node loss and stay identical across machines. That dependence is why the README pairs the project with a dedicated robustness testing suite, and why production adopters are recorded in ADOPTERS.md under critical deployment scenarios. The store is deliberately a key-value store, not a general database: the API surface is small, versioned and exposed over gRPC.

Key capabilities

  • User-facing gRPC API with versioned Go packages, including go.etcd.io/etcd/api/v3, go.etcd.io/etcd/client/v3 and go.etcd.io/etcd/client/pkg/v3.
  • Raft consensus for a highly-available replicated log, exposed as the go.etcd.io/etcd/raft/v3 package and served by go.etcd.io/etcd/server/v3.
  • Automatic TLS with optional client certificate authentication.
  • Benchmarked throughput of 10,000 writes per second.
  • etcdctl command line client, published as go.etcd.io/etcd/etcdctl/v3.
  • Pre-built release binaries for OSX, Linux, Windows and Docker.
  • Rigorous robustness testing maintained in the tests/robustness directory.

Who uses it and how

  • Kubernetes clusters, which the README names as a primary companion application and which appears directly in the project topic list.
  • Other named dependents including locksmith, vulcand and Doorman, each using etcd as the store behind its own coordination logic.
  • Production deployments by many companies, recorded in ADOPTERS.md, in critical deployment scenarios rather than experiments.
  • Operators who start with a single-member cluster, then move to replicated members while tracking stable releases instead of the development branch.
  • Contributors and maintainers across multiple companies, working under the governance described in OWNERS and the community membership documentation.

Getting started

The easiest way to get etcd is one of the pre-built release binaries for OSX, Linux, Windows or Docker, published on the release page, after which a single-member cluster is started from the installation location. Fuller installation guidance lives in the operating etcd guide at https://etcd.io/docs/latest/op-guide.

How it compares

The facts provided list no paid products that etcd replaces, and they name no peer key-value stores, so on that basis it stands alone in this registry rather than being contrasted against alternatives on licence, hosting or cost. What the facts do show is its position as a companion component: it is routinely teamed with Kubernetes, locksmith, vulcand and Doorman rather than sold against them.

When to use it — and when not to

A self-hoster must run and monitor a replicated cluster, manage membership and certificate lifecycle for TLS, and choose deliberately between pre-built stable releases and the main branch, which the README warns may be in an unstable or even broken state during development. Teams that cannot operate a consensus-backed cluster, or that need to build against a guaranteed stable branch, should not start from main and should track releases instead. The project also carries a visible open-issue backlog of 351 items, which is worth weighing before treating any single member as a drop-in store.

project readme (upstream, from github) — read inline

etcd

Go Report Card Coverage Tests codeql-analysis Docs Godoc Releases LICENSE OpenSSF Scorecard

Note: The main branch may be in an unstable or even broken state during development. For stable versions, see releases.

etcd logo

etcd is a distributed reliable key-value store for the most critical data of a distributed system, with a focus on being:

  • Simple: well-defined, user-facing API (gRPC)
  • Secure: automatic TLS with optional client cert authentication
  • Fast: benchmarked 10,000 writes/sec
  • Reliable: properly distributed using Raft

etcd is written in Go and uses the Raft consensus algorithm to manage a highly-available replicated log.

etcd is used in production by many companies, and the development team stands behind it in critical deployment scenarios, where etcd is frequently teamed with applications such as Kubernetes, locksmith, vulcand, Doorman, and many others. Reliability is further ensured by rigorous robustness testing.

See etcdctl for a simple command line client.

etcd reliability is important

Original image credited to xkcd.com/2347, alterations by Josh Berkus.

Documentation

The most common API documentation you'll need can be found here:

Maintainers

Maintainers strive to shape an inclusive open source project culture where users are heard and contributors feel respected and empowered. Maintainers aim to build productive relationships across different companies and disciplines. Read more about Maintainers role and responsibilities.

Getting started

Getting etcd

The easiest way to get etcd is to use one of the pre-built release binaries which are available for OSX, Linux, Windows, and Docker on the release page.

For more installation guides, please check out operating etcd.

Running etcd

First start a single-member cluster of etcd.

If etcd is installed using the pre-built release binaries, run it from the installation location as below:

/tmp/etcd-download-test/etcd

The etcd command can be simply run as such if it is moved to the system path as below:

mv /tmp/etcd-download-test/etcd /usr/local/bin/
etcd

This will bring up etcd listening on port 2379 for client communication and on port 2380 for server-to-server communication.

Next, let's set a single key, and then retrieve it:

etcdctl put mykey "this is awesome"
etcdctl get mykey

etcd is now running and serving client requests. For more, please check out:

etcd TCP ports

The official etcd ports are 2379 for client requests, and 2380 for peer communication.

Running a local etcd cluster

First install goreman, which manages Procfile-based applications.

Our Procfile script will set up a local example cluster. Start it with:

goreman start

This will bring up 3 etcd members infra1, infra2 and infra3 and optionally etcd grpc-proxy, which runs locally and composes a cluster.

Every cluster member and proxy accepts key value reads and key value writes.

Follow the comments in Procfile script to add a learner node to the cluster.

Install etcd client v3

go get go.etcd.io/etcd/client/v3

Next steps

Now it's time to dig into the full etcd API and other guides.

Contact

Community meetings

etcd contributors and maintainers meet every week at 11:00 AM (USA Pacific) on Thursday and meetings alternate between community meetings and issue triage meetings. Meeting agendas are recorded in a shared Google doc and everyone is welcome to suggest additional topics or other agendas.

Issue triage meetings are aimed at getting through our backlog of PRs and Issues. Triage meetings are open to any contributor; you don't have to be a reviewer or approver to help out! They can also be a good way to get started contributing.

The meeting lead role is rotated for each meeting between etcd maintainers or sig-etcd leads and is recorded in a shared Google sheet.

Meeting recordings are uploaded to the official etcd YouTube channel.

Get calendar invitations by joining etcd-dev mailing group.

Join the CNCF-funded Zoom channel: zoom.us/my/cncfetcdproject

Contributing

See CONTRIBUTING for details on setting up your development environment, submitting patches and the contribution workflow.

Please refer to community-membership.md for information on becoming an etcd project member. We welcome and look forward to your contributions to the project!

Please also refer to roadmap to get more details on the priorities for the next few major or minor releases.

Reporting bugs

S

readme truncated — read the full docs on github

Frequently asked questions

Is etcd free to use?

etcd is open source under the Apache-2.0 licence. There is no licence fee and no seat count — you can self-host it or, where the project offers one, pay a vendor for a managed version instead.

What does etcd do?

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

What is etcd written in?

etcd is primarily written in Go. Its source is publicly available at https://github.com/etcd-io/etcd, and it has 52,270 GitHub stars.