google/trillian: a Merkle tree data store in maintenance mode

What Trillian is for, and who the README tells to walk away

Trillian implements the concepts in the Verifiable Data Structures white paper, an extension of the ideas behind Certificate Transparency. The core object is a Merkle tree whose contents live in a data storage layer rather than in memory, which is what allows the tree to grow to very large sizes. On top of that tree the repository provides an append-only Log mode: the Merkle tree fills from the left, producing a dense tree.

The important structural point is that Trillian is not an application. The README states that it requires particular applications to provide their own personalities on top of the core transparent data store functionality. Certificate Transparency is the best known personality, and an implementation of it lives in the certificate-transparency-go repository rather than here. More examples are in trillian-examples. If you want a running log with a defined API for a specific ecosystem, you are adopting two repositories, not one.

The README opens with a note that Trillian is in maintenance mode. It says the next generation of transparency logs uses Tiled APIs and is better supported by Tessera, and that any new log operators should try Tessera first. That is the project speaking about itself, and it should shape the decision more than any feature list. The last push to the repository was on 2026-09-21, and v1.8.0 was released the same day, so the maintenance mode is not abandonment: it is a deliberate freeze on new features. The README says the codebase is stable and used in production by multiple organizations, including large-scale CT log operators, and that there are no plans to add new features, with incompatible code and schema changes avoided but not guaranteed never to be necessary.

How the Merkle tree, personalities and storage layer fit together

The architecture visible in the repository splits into a few clear layers. The merkle/ directory holds the tree logic. The log/ directory holds the log server side. The storage/ directory holds the backends, with a mysql/ subdirectory containing the schema at storage/mysql/schema/storage.sql. The trillian_log_api.proto and trillian_admin_api.proto files define the gRPC surface, and the generated Go files sit next to them at the repository root. The server/ directory holds the server wiring, and quota/ holds the quota implementations.

A personality sits above that stack. It decides what a leaf means, how it is serialized, and what the log promises to verifiers. Trillian itself only knows about leaves, tree heads and proofs. That separation is the reason the same core can back a CT log and the other examples in trillian-examples, and it is also the reason you cannot run Trillian and get a useful log without writing or adopting a personality.

Storage is a build-time choice, not only a runtime one. The README points to storage/README.md for build tags, and says anyone adding a new storage or quota implementation should understand how Trillian uses them. The build tags let you compile slimmer binaries that include only the storage and quota implementations you need. The go.mod file lists MySQL, PostgreSQL, Spanner, etcd and Redis client dependencies, so the repository carries several backends, but the README's own setup instructions only walk through MySQL.

Installing Trillian and running the first integration test

The README gives a short build path. You need Go 1.26 or later, and the go.mod file declares module github.com/google/trillian with go 1.26.0 and toolchain go1.26. Dependencies are fetched automatically through Go modules. To get the code and build everything:

git clone https://github.com/google/trillian.git
cd trillian

go build ./...

After that, go test ./... runs the unit tests. The README notes the repository also includes multi-process integration tests, which is where the database requirement appears.

For the integration tests you need MySQL or MariaDB listening on the standard port 3306, reachable as mysql --host=127.0.0.1 --port=3306, with no password required for the root user. The README's reset script destroys and recreates a test database using the expected tables from storage/mysql/schema/storage.sql:

./scripts/resetdb.sh
Warning: about to destroy and reset database 'test'
Are you sure? y
> Resetting DB...
> Reset Complete

The script prompts before wiping the database, so do not point it at anything you care about. Once the schema is in place, the end-to-end suite runs with:

./integration/integration_test.sh

According to the README, that script starts a Trillian server in Log mode together with a signer, logs many leaves, and checks they are integrated correctly. For a real deployment rather than a test, the README points at the deployment/ and examples/deployment/ directories instead of describing the process inline.

Where Trillian stops being the right tool

The clearest limitation is the one the project states itself: no new features. If your log needs a capability that is not already in the feature implementation matrix under docs/, you are not going to get it here. The README says incompatible code and schema changes will be avoided where possible but cannot be guaranteed never to be necessary, which is a weaker promise than a stable schema contract.

The second limitation is the personality requirement. Trillian does not define what your leaves mean. If you want a transparency log for a domain that has no personality yet, you are writing that layer, including the serialization and the verification story, before the Merkle tree does anything useful for you. The README does not document rollback or migration procedures for a deployed log, and it does not walk through production deployment inline; it defers to the deployment directories. Treat those as the place to look before you plan an upgrade.

The third is operational. The README's setup path assumes MySQL or MariaDB on port 3306 with a passwordless root for testing. That is fine for a test harness and unacceptable for production, so you will be configuring credentials and connectivity yourself. The tree lives in that storage layer, so database availability and schema handling become part of your log's availability. If you want a log without operating a relational database, this is not the project for you.

Tessera and the Tiled API direction

The README names the alternative directly: Tessera, in the transparency-dev organization, which it says better supports the next generation of transparency logs built on Tiled APIs. The difference in approach is not a matter of language or performance. Trillian serves a Merkle tree from a storage layer and exposes it through gRPC APIs defined by trillian_log_api.proto and trillian_admin_api.proto, with personalities layered on top. The Tiled API direction, as the README frames it, is the successor format for how log data is served, and Tessera is the implementation the project points new operators toward.

That leaves a practical split. If your existing code speaks the Trillian gRPC APIs, or you are adopting the CT personality in certificate-transparency-go, Tessera is not a drop-in replacement and the README does not claim it is. If you are starting a new log today, the project's own recommendation is to look at Tessera first. Choosing Trillian for a greenfield log means accepting maintenance mode on day one and accepting that the API surface you build against is the one the project is steering new users away from.

Maintenance cost, licensing and upgrade expectations

The repository is not archived, and the last push was on 2026-09-21, with v1.8.0 released the same day. The previous release, v1.7.3, came on 2026-03-30, and v1.7.2 on 2025-04-25. That cadence fits the stated posture: fixes and maintenance, not feature work. Upgrading between minor versions is the realistic activity, and the README's caution about incompatible schema changes means you should read the changelog and the storage schema before moving a production log forward.

The project is Apache-2.0 licensed. That permissive licence is a practical advantage for embedding Trillian in a commercial service, but the repository's dependency list is long, including cloud SDKs, database drivers, etcd and Kubernetes client libraries. Under Apache-2.0 you still carry the obligation to preserve notices, and the go.mod file shows the size of the transitive surface you would be shipping. The repository includes go-licenses in its dependency set, which suggests the maintainers generate licence reports, but the README does not document a licence audit workflow for downstream users. If your organization requires an inventory of third-party licences, plan to produce it yourself from go.sum rather than expecting it in the docs. None of this is legal advice; check your own obligations.

Editorial conclusion

Adopt Trillian only if you are maintaining an existing log or need the CT personality in certificate-transparency-go. New log operators should follow the README's own advice and evaluate Tessera first. Before committing, verify that your storage backend is on the supported list in storage/README.md, that your Go toolchain is 1.26 or later, and that a running MySQL or MariaDB on port 3306 with a passwordless root is acceptable for your environment. The project accepts community contributions, but the README asks you to file an issue or raise the change in Slack before sending code, so budget for that conversation as part of your upgrade path.

Frequently asked questions

Official sources

1. google/trillian on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases