AntidoteDB: a geo-replicated key-value database that trades global writes for CRDT semantics

Highly available transactions, and what they give up

AntidoteDB is described as a highly available geo-replicated key-value database, and the interesting part of that description is the second half.

The README's framing is that the database provides features that help programmers write correct applications while having the same performance and horizontal scalability as AP or NoSQL databases, and that operations are based on the principle of synchronization-free execution by using conflict-free replicated datatypes.

The consistency story is explained through what the project calls highly available transactions, HAT. The README's argument runs like this. Traditional ACID transactions were built for single-machine deployments. It is expensive to implement ACID transactions in distributed deployments, and on the other hand highly available transactions provide strong consistency within a data center but still perform well in geo-replicated deployments.

That is the whole trade in one sentence, and it is worth being precise about it. Consistency is strong inside a data centre, and across data centres the system relies on CRDT semantics to keep converging rather than on a distributed commit protocol. So the guarantee you get is not serialisability across continents. It is that concurrent updates to a CRDT type merge deterministically without the replicas having to coordinate at write time.

The other two features follow from that. CRDTs themselves are high-level replicated data types designed to work correctly in the presence of concurrent updates and partial failures. Geo-replication is designed to run on multiple servers in locations distributed worldwide, and it provides continuous functioning even when there are failures or a network partition.

The audience is therefore teams that need to write while partitioned. The project is the reference platform of the SyncFree European Project and the LightKone European Project, and both of those are academic programmes, which tells you where the design comes from and what kind of deployment it was built for.

Building the Erlang project, and the checks the maintainers run

The build is a standard rebar3 Erlang project, and the Makefile in the repository root is the entry point for everything.

The rebar3 binary is vendored in the tree, and the Makefile refers to it with a REBAR variable set to the absolute path of the local executable, so no globally installed rebar3 is needed. The basic targets are compile, which runs the rebar3 compile, and clean, which runs rebar3 clean. A release target builds an OTP release, and the shell target starts an interactive console with a node name and cookie set from the environment:

shell: rel
	export [email protected] ; \
	export COOKIE=antidote ; \
	export ROOT_DIR_PREFIX=$$NODE_NAME/ ; \
	_build/default/rel/antidote/bin/antidote console ${ARGS}

The test targets show how the project separates its test scopes. There is a plain eunit target, a proper target for property-based testing, a coverage target using rebar3 cover, and two common test suites run separately: singledc, which runs the suite in apps/antidote/test/singledc, and multidc, for apps/antidote/test/multidc. A systests target depends on both. The split is the clearest evidence of how the system is designed to be verified, single data centre behaviour and multi data centre behaviour as separate concerns with separate suites.

The quality gate is the check target, which chains distclean, test, reltest, dialyzer and lint. Dialyzer is in there, which is the standard Erlang type checker, and lint runs rebar3 lint plus rebar3 fmt --check for formatting. A relnocert target exists for building a release with NO_CERTIFICATION set, and the reltest target runs test/release_test.sh.

The repository also has an elvis.config, which is the linter configuration for Erlang style rules, and the top-level layout includes apps/, config/, monitoring/ and test/ directories, alongside AUTHORS.TXT and the licence files.

Docker and Kubernetes, and the port the local image exposes

The deployment story in the README is a list of options, and it is the most complete part of the visible documentation.

There are links for deploying Antidote natively, for a local Docker setup, for Docker Compose setups, for Docker Swarm and for Kubernetes. The README also links a monitoring project, antidote_stats, for monitoring an Antidote instance or a data centre, and a configuration page for configuring features of Antidote.

The Makefile has the Docker path, and it is worth looking at because it shows how the image is assembled. The docker-build target creates a temporary directory, downloads a Dockerfile from the docker-antidote repository with wget, and builds it tagged antidotedb:local-build against the current directory. The Dockerfile is deliberately not kept in this tree, which means the image definition lives in a separate repository and can be updated without touching the server code.

The run target is the line to note:

docker-run: docker-build
	docker run -d --name antidote -p "8087:8087" antidotedb:local-build

So a local instance is a detached container named antidote with port 8087 published to the host, and there is a docker-clean target that removes the image only if it exists, guarded by an ifneq so it does not fail on a machine without the image.

The deployment list is a fair summary of the intended production story. Native, Docker, Compose, Swarm and Kubernetes cover everything from a single machine to an orchestrated cluster, and the two Kubernetes-adjacent options matter for a geo-replicated system, because the data centre topology is what the CRDT and HAT machinery is built around.

The README's own pointer for how to use any of this is the project website and the usage documentation on gitbook, with a separate benchmarking repository linked for performance work.

Six client libraries, and a Protocol Buffer API in the middle

The client story is the part of Antidote that tells you most about its intended use.

The API is a Protocol Buffer API, and the README links a client repository for each of six languages: Erlang, Java, JavaScript, Go and Python under the AntidoteDB organisation, and a REST server maintained in the LightKone organisation. The JavaScript client is named antidote_ts_client, which points at a TypeScript implementation.

Six client libraries is a lot of surface area for a database, and it says something specific. This is a system meant to be used from applications in many languages, which is consistent with its academic origin and with a research goal of demonstrating that the CRDT and HAT approach is usable from ordinary application stacks rather than only from the language it was written in.

The REST client is worth a note because it is the odd one out. It lives under the LightKone organisation rather than AntidoteDB, which suggests it came from the other project and was adopted here. A REST interface is the pragmatic choice for anything that is not a JVM, Erlang, Go or Python process, and it is the lowest common denominator for a quick experiment.

Small tutorials are also linked, one for Java and one as a Jupyter Notebook. The Jupyter tutorial in particular suggests the intended way to evaluate the system, which is interactively, with a live cluster, from a notebook, rather than by reading papers about it.

Two applications built on Antidote are listed as well, a calendar app and an Antidote Web Shell, which is the sort of thing that gives you an idea of what the system feels like to drive.

Version 0.2.2 from 2019, and a repository still being pushed to

The version history is the most important thing to weigh before spending time on this, and it deserves plain statements rather than hedging.

The recent releases are v0.2.2, described as Improved DC and InterDC Functionality, from 2019-11-28, v0.2.1, Metrics, Configuration, and Performance, from 2019-11-14, and v0.1.1, Refactoring and cleaning up, from 2019-07-05. All three are from a single year, 2019, and the version numbers sit below 1.0.

The repository itself is not archived, and the last push was on 2026-06-17, on the master branch. So the code is being touched, roughly four months before this review, while the release tags stopped in 2019. That combination means the master branch is ahead of the last published release, and if you deploy from a tag you are deploying code from 2019, and if you build from master you are building something that has never been tagged.

The CI badge in the README shows an Erlang CI workflow, and there is a coverage badge pointed at coveralls for the master branch, which means the tests do run on the current branch rather than only on an old tag. The contributing section asks for help with good first issues and points at a developer documentation setup page, and the project states plainly that it encourages open source development.

So the honest reading is of an active research codebase rather than a maintained product. The architecture is sound and the ideas are good, and the deployment options are complete. What is missing is a release discipline: no tagged version since 2019, no semantic version contract, and no statement in the README about what a stable deployment looks like.

The licence is Apache-2.0, with LICENSE and LICENSE.TXT both at the root of the tree, which is a permissive grant with an explicit patent clause, so there is no obstacle to using, modifying or redistributing the code. This review does not interpret the terms, and it is worth noting that a permissive licence on the server does not automatically cover the separately maintained client repositories.

Editorial conclusion

AntidoteDB fits a research team or a product that genuinely needs writes to continue during a partition, that can express its data as CRDTs, and that wants strong consistency inside a single data centre, since that is where highly available transactions put their consistency guarantee. It is the wrong choice for a conventional transactional workload, where a single-node database with real ACID semantics is simpler and better understood, and it is the wrong choice if you need a maintained release train, because the newest tagged release is v0.2.2 from 2019-11-28 even though the repository was pushed to on 2026-06-17. Before you evaluate it, read the usage documentation on gitbook, and check the Erlang, Java, Go, Python and TypeScript client repositories, since the client you would actually use is maintained separately from the server.

Frequently asked questions

Official sources

1. AntidoteDB/antidote on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases