At DoltHub, we're building Dolt, the world's first SQL database that supports Git-like version control, including branch, merge, diff, clone, push and pull. Dolt is written in Go. Almost two years ago, my colleague Andy released an implementation of swiss tables, which was purpose built to be used for metadata tracking within Dolt's storage engine.

While Andy's implementation was not the first open source implementation of swiss tables in Go, it was one of the first ones that we know of that seemed to gain significant interest from the community.

For the last two years, swiss has been chugging along deep in the guts of Dolt, serving as the basis for one of the metadata indexes that Dolt has to consult every time it fetches data from disk.

Over time, other implemetations came along. Some of these were more full featured and made different performance tradeoffs. About a year ago, CockroachDB published cockroachdb/swiss on GitHub, which was a more full-featured map implementation based on swiss tables. Most recently, and most significant of all, Go 1.24 shipped with swiss tables as the foundation of Go's map implementation. We thought it was very cool to see Andy called out in the Acknowledgements of the Go release blog.

dolthub/swiss was always a purpose built, pointy tool serving a particular niche in Dolt's storage engine. Dolt, for the most part, continued to use regular Go maps for the vast majority of its needs, and only used swiss for a few particularly large, essentially append-only, and highly latency sensitive maps. Dolt's use case and requirements ended up being somewhat at odds with growing the functionality dolthub/swiss and even with stewarding community contributions.

With the recent release of Go 1.24, we have had some users reach out to us to ask us about the future of dolthub/swiss. This week, I got a chance to upgrade our toolchains to Go 1.24 and to evaluate the performance impact of the new native map implementation on Dolt, compared to dolthub/swiss. What we found was that the performance of the new maps, for our use case, was even a bit faster than dolthub/swiss. Additionally, their growth strategy was very attractive from a tail latency standpoint.

As a result of these findings, we decided to remove the remaining use of dolthub/swiss from Dolt. As a result of no longer having a production use case for dolthub/swiss itself, and our belief that there are other compelling alternatives available in the community, we are also choosing to archive the dolthub/swiss GitHub repository. We believe that this best signals our intentions for our future involvement with the repository and is the best way to minimize any potential confusion going forward.

It feels great that we were able to deliver and rely on a quality swiss table implementation that served our needs well for two years. It also feels great to remove dependencies, to delete unnecessary code, and to migrate to standard components which will require almost no engineering investment to reap the benefits of going forward. The fact remains—there's no code like no code.

The entire story of dolthub/swiss represents a big win for us and for the Go community at large. We continue to be impressed with the community and the Go team and we are very happy with our continued investment in Go and its ecosystem as a foundational part of our tech stack.

If you want to talk swiss tables, Go release versions, or superceded depenendencies, drop by and reach out on our Discord server. We hope to see you there!