Simple Binary Encoding: a codec generator for low-latency financial messages

What SBE is for, and who actually needs it

SBE is defined in the README as an OSI layer 6 presentation for encoding and decoding binary application messages for low-latency financial applications. That framing matters. It is not a general-purpose serialization format for web services or storage. It targets the case where two processes exchange a high rate of small, well-specified messages and the cost of encoding and decoding sits directly on the critical path.

The repository is the reference implementation, not a single library. It contains generators for Java, C, C++, C#, Golang and Rust. A team using SBE writes an XML schema, runs the generator, and gets source code in its target language. That generated code is what ships. The generator is a build-time tool; the generated codecs are ordinary source files with no SBE runtime dependency, which is why the Rust generator can state that generated crates have no dependencies on any libraries, including no SBE libraries.

The audience is narrow by design: trading systems, market data handlers, and any system where a schema is stable enough to be compiled rather than interpreted at runtime. If your message shapes change weekly and you deploy decoders independently of encoders, this is the wrong shape of tool.

The mechanism: XML in, fixed-layout codecs out

The data flow is one-directional. You author an XML message schema. The sbe-tool jar reads it and emits source code for the language you name. The README's own command-line example shows the flags that control this: sbe.target.language selects the output language, sbe.target.namespace sets the package or namespace, sbe.output.dir sets where files land, sbe.errorLog turns on an error log, and sbe.generate.ir asks for an intermediate representation.

Because the layout is fixed and known at generation time, the generated code can read fields directly out of a buffer rather than parsing a stream. That is the whole point of the design, and it is also where the constraints come from: schema changes are code changes, and both ends of a connection must agree on the schema version.

The Java implementation depends on Agrona for its buffer implementations, and the README notes that the Java and C++ implementations work efficiently with the Aeron messaging system. That pairing is not accidental. Aeron provides the transport, SBE provides the wire format, and the two share an author lineage. If you are already running Aeron, the integration path is the documented one; if you are not, SBE still generates standalone codecs, but you are assembling the rest yourself.

Installing sbe-tool from Maven Central and generating your first codec

The README points to Maven Central for binaries and dependency information, and gives the Maven coordinates directly. The groupId is uk.co.real-logic and the artifactId is sbe-tool. Add it to your build with the version property your project defines.

<dependency>
    <groupId>uk.co.real-logic</groupId>
    <artifactId>sbe-tool</artifactId>
    <version>${sbe.tool.version}</version>
</dependency>

The sbe-all jar bundles the Agrona dependency, so it can be run directly from the command line without assembling a classpath. The README gives this invocation, which generates C++ code into include/gen from a schema file named my-sbe-messages.xml:

java --add-opens java.base/jdk.internal.misc=ALL-UNNAMED -Dsbe.generate.ir=true -Dsbe.target.language=Cpp -Dsbe.target.namespace=sbe -Dsbe.output.dir=include/gen -Dsbe.errorLog=yes -jar sbe-all/build/libs/sbe-all-${SBE_TOOL_VERSION}.jar my-sbe-messages.xml

After it runs, the output directory should contain the generated namespace, and the error log setting means generation failures are reported rather than silently skipped. Note the --add-opens flag: it is required on modern JDKs because the tool reaches into jdk.internal.misc. Drop it and the tool will not start.

If you are building the project itself rather than consuming the jar, the README gives a Gradle path. A full clean build is ./gradlew, and ./gradlew runJavaExamples runs the Java examples. Each language has its own generation target: ./gradlew generateGolangCodecs, ./gradlew generateRustCodecs, and ./gradlew runRustTests. The C++ build goes through CMake instead, with a cppbuild script that does a full clean, build, and test as a Release build.

Language coverage is not uniform, and the README says so

The headline claim is six languages, but the depth of support differs and the README is unusually candid about one of them. The C++ build section states in a note that the C++ build includes the C generator and that the C generator is currently a work in progress. That is a direct statement from the project, and it should shape planning. If C is on your target list, you are adopting something the maintainers describe as unfinished.

The Golang path has its own wrinkle. Structs with encode and decode methods are generated by default for compatibility, and flyweights are opt-in via the setting sbe.go.generate.generate.flyweights=true. Those two output styles have different performance and ergonomic profiles, so the default is not automatically the right choice for a latency-sensitive service. The README points Golang users to a separate user guide on the wiki for the details.

Rust is the most constrained by design: the generator emits 100% safe Rust with no unsafe code and no library dependencies in the generated crates. That is a deliberate trade-off. It buys you a generated crate that drops into a project without dragging in a runtime, and it costs whatever the safe subset cannot express. C# users likewise have a dedicated user guide on the wiki rather than instructions in the README.

Java gets the most attention, which is unsurprising given the repository's primary language and its Agrona dependency. The Javadoc badge in the README points at the sbe-tool artifact, so the Java API surface is the one with published reference documentation.

Where SBE is the wrong tool, and how it differs from Protobuf

The most common comparison is with Protobuf, and the difference is architectural rather than a matter of degree. Protobuf ships a runtime library that parses a self-describing wire format at decode time; field presence, tags and lengths are handled by that runtime. SBE generates code ahead of time from a schema and lays fields out at fixed offsets, so decoding is a read rather than a parse. That removes the runtime from the hot path, and it also removes the flexibility the runtime provides.

Practically, that means SBE is a poor fit when consumers and producers are deployed independently and schemas evolve faster than you can regenerate and redeploy both sides. It is also a poor fit when you need to store messages for years and read them back with tooling that does not know your schema, because a fixed-layout binary message is opaque without the schema that generated it. And it is a poor fit for a service where serialization cost is not measurable against network and database time. The design pays off only when encoding and decoding are a visible share of your latency.

Two more limits are worth stating plainly. The README does not document a rollback procedure for a schema change that turns out to be wrong, so versioning discipline is on you. And the specification itself is not owned by this repository: the README directs questions about the specification to the SBE FIX community, and points at an XSD in sbe-tool/src/main/resources/fpl/sbe.xsd. This repository is the reference implementation of someone else's specification, which matters if you need to influence the format.

Maintenance, releases and the Apache-2.0 licence

The repository is not archived, and the last push was on 2026-09-17. Releases are frequent: 1.40.0 and 1.40.1 both landed on 2026-08-21, and 1.40.2 followed on 2026-09-17. The README points to a Change Log on the wiki for version information, and to Maven Central for downloads. There is a version.txt at the repository root, and the README's command-line example references an SBE_TOOL_VERSION variable, so pinning a version is a normal part of consuming this tool.

The upgrade cost is concentrated in the generator, not in a runtime you link against. Regenerating codecs against a newer sbe-tool can change the generated source, and any such change has to be reviewed and redeployed on both ends of a connection. The sbe.generate.ir flag in the README's example suggests generated intermediate representations are available, which is useful for diffing output across tool versions, though the README does not explain the format.

On licensing: the project is Apache-2.0. The README carries the standard Apache notice, with copyright attributed to Real Logic Limited from 2013 to 2025 and to MarketFactory Inc from 2017. Apache-2.0 is permissive and includes a patent grant, but the generated code inherits the terms of whatever you generate it with, and the README does not discuss licensing of generated output. If that distinction matters to your legal team, it is a question for them, not something this page can settle.

Editorial conclusion

Adopt SBE when your messages have a known schema, a fixed layout, and a latency budget that rules out a general-purpose serialization runtime; the Java and C++ paths are the ones the README describes in most detail, and the C generator is described there as a work in progress. Do not adopt it if you need schema evolution without regenerating and redeploying code, or if you cannot commit to keeping an XML schema as the source of truth. Before you commit, verify two things: that your target language's generated code satisfies your correctness requirements, and that the C generator's incomplete status is acceptable if C is on your list.

Frequently asked questions

Official sources

1. aeron-io/simple-binary-encoding on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases