# Protocols, clients and SDKs

This getting started guide shows you how to get started with EventStoreDB by setting up an instance or cluster and configuring it.

EventStoreDB supports two protocols: TCP and HTTP (Atom). When developing software that uses EventStoreDB, we recommend using one of the official SDKs.

# TCP protocol

EventStoreDB offers a low-level protocol in the form of an asynchronous TCP protocol that exchanges protobuf objects. At present this protocol has adapters for .NET and the JVM.

# EventStoreDB supported clients

# Community developed clients

# HTTP

EventStoreDB also offers an HTTP-based interface, based specifically on the AtomPub protocol. As it operates over HTTP, this is less efficient, but nearly every environment supports it.

# EventStoreDB supported clients

# Community developed clients

If you have a client to add, click the 'Improve this Doc' link on the top right of the page to submit a pull request.

# Which to use?

Many factors go into the choice of which of the protocols (TCP vs. HTTP) to use. Both have their strengths and weaknesses.

# TCP is faster

This speed especially applies to subscribers as events pushed to the subscriber, whereas with Atom the subscribers poll the head of the atom feed to check if new events are available. The difference can be as high as 2–3 times higher (sub 10ms for TCP, vs. seconds for Atom).

Also, the number of writes per second supported is often dramatically higher when using TCP. At the time of writing, standard EventStoreDB appliances can service around 2000 writes/second over HTTP compared to 15,000-20,000/second over TCP. This increase might be a deciding factor if you are in a high-performance environment.

# AtomPub is more scalable for large numbers of subscribers

WARNING

We do not recommend developing new applications and systems that use the AtomPub feature of EventStoreDB as it is being deprecated in the core product. Take a look at the gRPC streaming in EventStoreDB 20.6+ instead.

This scalability is due to the ability to use intermediary caching with Atom feeds. Most URIs returned by EventStoreDB point to immutable data and are infinitely cachable. Therefore on a replay of a projection, much of the data required is likely available on a local or intermediary cache. This can also lead to lower network traffic.

Atom tends to operate better in a large heterogeneous environment where you have callers from different platforms. This is especially true if you have to integrate with different teams or external vendors. Atom is an industry standard and well-documented protocol whereas the TCP protocol is a custom protocol they would need to understand.

Most platforms have good existing tooling for Atom including feed readers. None of this tooling exists for analyzing traffic with the TCP protocol.

Last Updated: 10/12/2020, 9:01:06 PM