Apache Fory: a serialization framework that wants your domain objects, not wrappers

Three modes that solve different problems

The easiest way to get lost in Fory is to treat it as one thing. The README describes at least four distinct modes, and they make different trade-offs.

There is cross-language mode, which is the headline: compact binary encoding, metadata packing, schema evolution, shared and circular references, and polymorphic runtime types, exchanged between any supported pair of languages. There is a reference-aware schema IDL, which lets you define schemas once and generate native domain objects per language, with shared and circular references expressible directly in the schema alongside numbers, strings, lists, maps, arrays, enums, structs and unions.

Then there are the same-language modes. Java native serialization is positioned as a high-performance replacement for JDK serialization, Hessian, Kryo and FST, and it supports JDK custom serialization semantics. Python native serialization is the equivalent for `pickle` and `cloudpickle`, covering classes, modules, functions and custom object state, with fine-grained control through `DeserializationPolicy`. And there are specialized formats: a row format for partial reads, and Fory JSON, a separate Java framework built around runtime-generated codecs.

Why zero-copy needs a row format

Row format is the piece that separates Fory from the usual serialization argument. A normal object serializer has to build the object graph before you can touch it, which means allocating a representation of all of it just to read two fields.

The row format skips that. You get direct access to fields, arrays, collection elements and nested values without reconstructing complete objects, with zero-copy access and partial reads. The Go implementation added this in v1.7.3, published 2026-09-15, and the release notes point out that it enables row data exchange with Java, C++, Python and Rust.

If your workload is columnar rather than object-shaped, and you are moving tabular data between services, this is the mode that changes the economics. If your workload is ordinary request and response objects, the row format is something you will read about and not use.

Where the implementations get their speed

The README is specific about the mechanism rather than vague about it. Java uses JIT serializers, generated at runtime. Other language implementations use generated or static serializers. That distinction matters because it explains why the speed claims are not evenly distributed across languages: the Java path has been worked on hardest and has the broadest benchmark comparison set.

The Java numbers are also the ones the project puts first, with a claim of up to 170x the throughput of JDK serialization on selected workloads. Read that carefully. Selected workloads is doing real work in that sentence, and the supporting charts live under `docs/benchmarks/`, with separate pages for C++, Go, JavaScript and TypeScript, C#, Swift and Dart, plus Python and Rust under `benchmarks/`.

The repository tree explains the shape of the effort. Alongside `java/`, `python/`, `go/`, `rust/`, `cpp/`, `javascript/`, `kotlin/` and `scala/`, there are `csharp/` and `swift/`, a `compiler/` directory, `benchmarks/`, `integration_tests/`, `examples/` and `docs/`. A `compiler/` directory in a serialization project implies code generation is part of the design, not an afterthought.

Build system, governance and what the README leaves out

Apache Fory builds with Bazel. The tree carries `MODULE.bazel`, `WORKSPACE`, `BUILD`, `.bazelrc` and a pinned `.bazelversion`, plus a `bazel/` directory, and there is a `Package.swift` for the Swift implementation. Release notes through v1.7.4 reference pull requests in the 4,000 range, which is a project with substantial continuous contribution behind it.

The Apache governance files are all present: `NOTICE`, `licenses/`, `licenserc.toml`, `CONTRIBUTING.md`, `SECURITY.md`, `CODE_OF_CONDUCT.md` and `.asf.yaml`. The license is Apache-2.0, which for a library that ends up inside other people's distributions is a more consequential choice than MIT, and worth reading properly rather than skimming.

There are also `AGENTS.md`, `CLAUDE.md`, `.agents/` and `.claude/` directories at the root, plus an `AI_POLICY.md`. Seeing an AI policy file at the top level of an Apache project in 2026 is unremarkable, but the presence of agent instruction files alongside it is a signal about how much of the contributor workflow is automated.

The README itself stops right after the benchmark section. It contains no install command, no dependency coordinates in a copyable form, and no usage example. The badges point at Maven Central for `org.apache.fory:fory-core`, crates.io for `fory`, PyPI for `pyfory`, npm for `@apache-fory/core`, NuGet for `Apache.Fory` and pub.dev for `fory`:

fory-core
pyfory
@apache-fory/core

Everything beyond the package names lives at fory.apache.org, which the README treats as the real documentation.

Where Fory fits, and where it does not

The comparison every reader has is against Protobuf, and it is worth being blunt about the difference in approach. Protobuf is schema-first and language-neutral: you write an IDL, generate stubs, and the wire format is a public contract that survives both sides changing. Fory's cross-language mode is object-first, so you can send a Python dataclass or a Go struct without generating anything, at the cost of a binary format that only Fory implementations can read.

That is a fine trade inside one organisation and a bad one across a boundary you do not control. If a partner, a mobile client on an old OS version, or a third-party integration has to read your payloads, a self-describing schema you own is the safer contract.

There is also the security dimension nobody puts on the front page. Native mode in both Java and Python is explicitly a replacement for mechanisms, JDK serialization and `pickle`, that have well-known deserialization attack surfaces. Fory supports JDK custom serialization semantics, which also means it inherits the risk profile of whatever those semantics do. Deserialize only from peers you trust, and treat that as a design constraint rather than a warning label.

Editorial conclusion

Fory is worth a look when your traffic crosses a language boundary and both sides would rather not negotiate a schema, or when a Java service is genuinely bottlenecked on JDK serialization and you control both ends. It is the wrong tool if you need a stable, language-neutral wire format that a third party will implement against, because the compact binary encoding is the other side of that trade. The last push was on 2026-09-22 and v1.7.4 shipped on 2026-09-20, so the project moves fast. Start by reading the Java native serialization page for a single-language case, and the schema IDL documentation before assuming it can express your object graph.

Frequently asked questions

Official sources

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