This couldn't have come at a better time - I was actually looking for a durable message-queue written in Go. Is there any way to read more about the architecture of this system? I find systems like these to be quite fascinating but taking the time to go through the code can sometimes be very time-consuming. It would be awesome if more projects have a writeup as detailed as cockroachdb[0]!
Aside: There used to be a site sometime back which used to distribute compiled binaries of Go code for all platforms? Is it still up any chance?
[0] - https://github.com/cockroachdb/cockroach#architecture
In Siberite: A Simple LevelDB-Backed Message Queue in Gocockroachdb
cockroach
Go2014–2026
cockroachdb / cockroach
cockroach
CockroachDB — the cloud native, distributed SQL database designed for high availability, effortless scale, and control over data placement.
114Distinct people
170Mentions
1Explicit recommenders
32.6KGitHub stars
What to know before exploring
What it is
CockroachDB — the cloud native, distributed SQL database designed for high availability, effortless scale, and control over data placement.
GitHub
Where it is used
- DoorDash — DoorDash runs CockroachDB as a fully abstracted internal database service for its engineering organization. DoorDash leverages it to meet availability goals at massive scale. Source
- City Storage Systems — City Storage Systems uses CockroachDB to run Tier 0 applications, migrating their order management system and user authentication platform to it. They replaced some PostgreSQL use cases with CockroachDB for these critical apps. Source
- 1 more documented example
What people are saying
Tried it before. Compatibility depends on how complicated your SQL is. There's a detailed list of supported syntax which is getting better every release but it's best for…
manigandham used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- kubernetes/kubernetes · linked in 2 of the same discussions
- moby/moby · linked in 2 of the same discussions
- pingcap/tidb · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 12:03:30 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year170 dated mentions
Observed mentions: 2014-05-26 11:44:43 UTC to 2026-08-11 19:04:13 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 9 | 6 | 3 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 17 | 2 | 15 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 20 | 0 | 20 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 46 | 1 | 45 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 18 | 1 | 17 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 16 | 0 | 16 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 14 | 1 | 13 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 10 | 0 | 10 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
CockroachDB is a cloud-native distributed SQL database designed to build,
scale, and manage modern, data-intensive applications.
What is CockroachDB?
Docs
Starting with Cockroach Cloud
Starting with CockroachDB
Client Drivers
Deployment
Need Help?
Contributing
Design
Comparison with Other Databases
See Also
What is CockroachDB?
CockroachDB is a distributed SQL database built on a transactional and
strongly-consistent key-value store. It scales horizontally;
survives disk, machine, rack, and even datacenter failures with
minimal latency disruption and no manual intervention; supports
strongly-consistent ACID transactions; and provides a familiar
SQL API for structuring, manipulating, and querying data.
For more details, see our product overview, FAQ or architecture document.
Docs
For guidance on installation, development, deployment, and administration, see our User Documentation.
Starting with CockroachCloud
We can run CockroachDB for you, so you don't have to run your own cluster.
See our online documentation: Quickstart with CockroachCloud
Starting with CockroachDB
Install CockroachDB: using a pre-built executable or build it from source.
Start a local cluster and connect to it via the built-in SQL client.
Learn more about CockroachDB SQL.
Use a PostgreSQL-compatible driver or ORM to build an app with CockroachDB.
Explore core features, such as data replication, automatic rebalancing, and fault tolerance and recovery.
Client Drivers
CockroachDB supports the PostgreSQL wire protocol, so you can use any available PostgreSQL client drivers to connect from various languages.
For recommended drivers that we've tested, see Install Client Drivers.
For tutorials using these drivers, as well as supported ORMs, see Example Apps.
Deployment
CockroachCloud - Steps to create a free CockroachCloud cluster on your preferred Cloud platform.
Manual - Steps to deploy a CockroachDB cluster manually on multiple machines.
Cloud - Guides for deploying CockroachDB on various cloud platforms.
Orchestration - Guides for running CockroachDB with popular open-source orchestration systems.
Need Help?
CockroachDB Community Slack - Join our slack to connect with our engineers and other users running CockroachDB.
CockroachDB Forum and Stack Overflow - Ask questions, find answers, and help other users.
Troubleshooting documentation - Learn how to troubleshoot common errors, cluster setup, and SQL query behavior.
For filing bugs, suggesting improvements, or requesting new features, help us out by opening an issue.
Building from source
See our wiki for more details.
Contributing
We welcome your contributions! If you're looking for issues to work on, try looking at the good first issue list. We do our best to tag issues suitable for new external contributors with that label, so it's a great way to find something you can help with!
See our wiki for more details.
Engineering discussions take place on our public mailing list, cockroach-db@googlegroups.com. Also please join our Community Slack (there's a dedicated #contributors channel!) to ask questions, discuss your ideas, and connect with other contributors.
Design
For an in-depth discussion of the CockroachDB architecture, see our
Architecture
Guide.
For the original design motivation, see our design
doc.
Licensing
All versions released on or after November 18, 2024 (specifically, major version series v24.3 and later, and patch fixes for v23.1.29+, v23.2.16+, v24.1.7+, and v24.2.5+) are published under the CockroachDB Software License (CSL). Source code in a given file is licensed under the CSL and the copyright belongs to The Cockroach Authors unless otherwise noted in the file or in a LICENSE or README file located in the same or a parent directory of the file.
Comparison with Other Databases
To see how key features of CockroachDB stack up against other databases,
check out CockroachDB in Comparison.
See Also
Tech Talks (by CockroachDB founders, engineers, and customers!)
CockroachDB User Documentation
The CockroachDB Blog
Key design documents
Serializable, Lockless, Distributed: Isolation in CockroachDB
Consensus, Made Thrive
Trust, But Verify: How CockroachDB Checks Replication
Living Without Atomic Clocks
The CockroachDB Architecture Document
Read the full README on GitHubWhat Hacker News says
17 sourcesPost author here:
In terms of Google products, CockroachDB much more closely resembles a combination Spanner (http://research.google.com/archive/spanner.html) and F1 (http://research.google.com/pubs/pub41344.html). However, while we do share many traits with these systems (a consistently replicated, transactional key/value store with a SQL interface), our internal transactional model is actually quite different.
If you're interested in some of the papers that inspired CockroachDB's transactional model, we have mentioned a number of them in our design doc (https://github.com/cockroachdb/cockroach/blob/master/docs/de...).
As for Percolator, that system is not a general purpose database but an "incremental processor" for large datasets (such as a web crawler). While it does use a snapshot transaction system internally, it appears to use re
Read the rest
al exclusive access locks, which CockroachDB does not use. Our write intents are not locks, because they do not guarantee exclusive access to a resource (I've expanded on this in another comment on the blog: http://www.cockroachlabs.com/blog/how-cockroachdb-distribute...)
We are not claiming our transaction model to be exceptionally novel, this post is just trying to shed light on a specific property of that model.
Post author here
Sargun is correct, all of our replication is performed by Raft, which exists at a lower level than the content covered in this post. Every command executed against a cockroach key (i.e. "create write intent", "begin this transaction") is persisted to the Raft log before executing; Commands will not proceed if they are not confirmed by Raft. The outcome of all commands is deterministic, so this provides complete replication of all mutations to each key.
If you're interested, there's more information available in our primary design document:
(https://github.com/cockroachdb/cockroach/blob/master/docs/de...)
In How CockroachDB Does Distributed, Atomic TransactionsHi there, blog author here!
This blog post is not a full description of CockroachDB's transaction strategy. If you're interested, you can find a complete rundown of our strategy here: (https://github.com/cockroachdb/cockroach/blob/master/docs/de...). However, that is a very terse document: this blog post was an attempt to expand on one of the basic ideas behind our design. My goal to clearly explain how we approach atomicity, without broaching the complicated topic of Isolation.
That said, I will attempt to address some of the pain points you raised:
* Cockroach does use a full MVCC system; writes are "append-only" and we keep the full history of values for each key. Keys can be queried at a timestamp, and every write explicitly specifies a timestamp as well (each transaction is assigned a timestamp, all writes will use the same timestamp
Read the rest
). With this system, each transaction operates on a snapshot of the database.
* Our strategy for overlapping transactions is straightforward: if two concurrent transactions have a conflict, one of them will be aborted and retried. Write intents (in combination with another component, the "read timestamp cache") are used by conflicting transactions to discover each other. Once discovered, the decision of which in-progress transaction gets aborted is deterministic - each transaction is assigned a random integer "priority", and the transaction with the highest priority always wins the conflict (unless one of the transactions has already committed).
* Every read does need to check the switch if the key being read has a write intent; reads of plain values (with no in-progress transaction) do not need to check a switch.
* Yes, aborted transactions can write intents to the database in our current system. However, the second "write" (consolidation) happens asynchronously, and is not required for the transaction to function correctly. It should only be noticed if the key is accessed again by another transaction before it is consolidated. For committed transactions, I don't believe this is a particularly high price to pay.
A system that doesn't write aborted transactions to disk would be considerably more complex; I think it would involve two commit phases (I. The transaction has been "committed" in memory, and can no longer be aborted by other transactions II. The transaction must successfully commit all changes to disk in an atomic fashion). You likely could get some additional performance (if disk latency is a sufficient bottleneck), but it would be hard won in terms of complexity.
I'm not at all associated with the Cockroach folks, but I'm pretty sure they actually do use MVCC, and the description they gave in this post is a simplification of the actual implementation. At least, there are a bunch of references to MVCC in their codebase: https://github.com/cockroachdb/cockroach/tree/master/storage...
In How CockroachDB Does Distributed, Atomic TransactionsNot too far off.
There's your discovery layer:
https://en.wikipedia.org/wiki/Kademlia
C&C:
http://www.reddit.com/r/netsec/comments/2pmmfu/using_the_blo...
Persistence Layer:
https://github.com/cockroachdb/cockroach
Dissemination Layer:
https://en.wikipedia.org/wiki/Gossip_protocol
Sprinkle in some AES and public / private keys for verification and you're done.
Sequential list isn't needed.
(well, all the robust & stealthy large systems engineering together with the low level exploit knowledge is probably a little too much for one person to pull it off, but for a Hacking Team or nation sized actor it's quite doable)
In Major Flaw in Android Phones Would Let Hackers in with Just a TextCockroachDB: A Scalable, Geo-Replicated, Transactional Datastore
1 points · Open discussionThe new Cockroachdb implementing in GOlang https://github.com/cockroachdb/cockroach
In Go vs. Rust: Productivity vs. Performance (2014)CockroachDB: A Scalable, Geo-Replicated, Transactional Datastore
3 points · Open discussionI suspect they have figured out the hard part.
If you look at the documentation (eg., [1]), the design has been rather carefully thought out; it's just that they're implementing it from the bottom up.
According to their roadmap [2], they're aiming for KV functionality in 1.0 and aren't aiming for SQL until past version 2.0 (it's currently alpha).
Given the backgrounds of the technical people involved (including Google, as this project is inspired by Spanner), they should have a lot of experience with what they're trying to accomplish.
As for "done before", a core feature of Cockroach is true ACID transaction support, including snapshot isolation, something no distributed NoSQL database I know about supports. (ArangoDB does support transaction, but is mostly NoSQL in the sense of implementing a different query language than SQL.)
[1] https
Read the rest
https://github.com/cockroachdb/cockroach
"The highest level of abstraction is the SQL layer (currently not implemented)."
In Hello WorldFrom here [0]:
"The highest level of abstraction is the SQL layer (currently not implemented)"
[0] https://github.com/cockroachdb/cockroach#architecture
In Hello WorldThe design page is the most interesting place to look at: https://github.com/cockroachdb/cockroach/blob/master/docs/de...
In Hello WorldIf you like the article, you might like CockroachDB. They just got funded by Google Ventures.
https://github.com/cockroachdb/cockroach#design
https://twitter.com/GoogleVentures/status/606534505332154369
In Distributed Systems Are a UX ProblemWorth following the development of cockroachdb
https://github.com/cockroachdb/cockroach
The long term goals of that project seem to align.
In Apple Acquires FoundationDBShowing the 15 most recent of 17 sources. Enable JavaScript to search and browse every indexed mention.