https://github.com/cockroachdb/cockroach
CockroachDB heavily utilizes RocksDB.
In RocksDB: A Persistent Key-Value Store for Flash and RAM Storagecockroachdb
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, 8:01:28 AM 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
20 sourcesCockroach Labs employee here - the implementation only uses a single context key, so traversing the context linked list is only necessary when the context in hand is a derivative of the annotated context (e.g. obtained via WithTimeout or WithCancel), which is relatively uncommon in practice.
https://github.com/cockroachdb/cockroach/blob/6b0698f/pkg/ut...
In Enriching Log Messages Using Go Contextsi've personally found using Reviewable[0] to be a delight, automatically plugs in your github workflow in that it modifies the comments in your original PR with comments left on reviewable itself. one killer feature is their batch comment mode, the ability to draft up a whole set of comments and publish in one go all the while tracking the resolution/conversation of each point brought up.
an example of this is here[1], batched comments with the multiple threads of discussions across various revisions and tracked to resolution.
[0]: https://reviewable.io
[1]: https://github.com/cockroachdb/cockroach/pull/10618
In Show HN: GitPlex – A new Git repo management server with code review[cockroach labs employee] most of the 'stability' related PRs/isues were labelled explicitly [1].
Going over the ones with the heaviest discussions could maybe point you to what you were looking for [2].
[1]https://github.com/cockroachdb/cockroach/labels/stability
[2]https://github.com/cockroachdb/cockroach/issues?utf8=%E2%9C%...
In CockroachDB Stability Post-Mortem: From 1 Node to 100 NodesThey also recently got joins working[1], so it's pretty close now to being like etcd, but with sql instead of KV.
Once they get to the rest of the stability and performance roadmap milestones, it seems like they are positioned to be a great backing store for a lot of interesting use cases.
Nice work!
[1] https://github.com/cockroachdb/cockroach/issues/2970
In CockroachDB Stability Post-Mortem: From 1 Node to 100 Nodesyeap, interning this semester at Cockroach Labs, Inc.[1] where their central project CockroachDB[2] is open sourced under Apache-2.0.
[1]: https://www.cockroachlabs.com/
[2]: https://github.com/cockroachdb/cockroach/
In Ask HN: Do you get paid to contribute to a open source project?https://github.com/cockroachdb/cockroach
which was inspired by this paper:
http://research.google.com/archive/spanner.html
which google made available for all in form of it's cloud datastore:
https://cloud.google.com/datastore/
"We believe it is better to have application programmers deal with performance problems due to overuse of transactions as bottlenecks arise, rather than always coding around the lack of transactions." [1]
[1] http://highscalability.com/blog/2012/9/24/google-spanners-mo...
In Consistency is Consistently Undervalued> Reading their FAQs I don't think they understand how consistency works, or the CAP theorem.
I'm going to try to avoid being rude, but it's very clear you just haven't done more than a cursory glance at their material and don't even know the broad shape of what you're disparaging.
Cockroach follows the same general pattern as spanner. The database is sharded into independent subranges or spans. Each span is hosted by a group of replicas using raft consensus. Transactions use a lock free 2 phase protocol atop the sea of raft replica sets.
This general pattern is a nice design that I expect to become increasingly common over the next decade. The consensus groups are fault tolerant, so the transaction protocol avoids the classic problem with distributed two phase commit not tolerating failure of the coordinator. It allows horizontal scalabi
Read the rest
lity for transactions that don't interfere with each other, and preserves correctness and consistency for those that do via the transaction protocol. Read the spanner paper for more about this general idea.
This is a state of the art design, that you would not be capable of producing without reading the majority of the distributed systems literature published in the last 2 decades.
They know what CAP is.
The design is nothing like couchbase. Systems like spanner and cockroach are capable of full Serializable Snapshot Isolation. They provide point in time snapshot reads across the entire distributed system, including points of time in the past (it's explicitly a multi-version database). These systems can provide full external consistency. Again, this is nothing like couchbase. Couchbase has it's advantages, and some applications can tolerate the lack of consistent reads and only single document atomicity.
Read https://github.com/cockroachdb/cockroach/blob/master/docs/de... to pick up what you missed about cockroach specifically.
I've read most of their design documents and commentaries since the very start and it's clear they've read the bulk of the distributed systems literature, including some of the most novel papers to be published in the few years. Here's two papers that they've referenced as inspiring/informing their design that I particularly like:
http://users.ece.utexas.edu/~garg/pdslab/david/hybrid-time-t...
https://drive.google.com/file/d/0B9GCVTp_FHJIMjJ2U2t6aGpHLTF...
It looks like you were already somewhat aware that you'd not understood what the design is or what its properties are. I'd encourage you check into things a bit more and be sure you really do know what you think you know before making disparaging remarks.
For scalable SQL products, I'd consider Google's Spanner to be in that boat. There is actually a class of products trying to do this under the name of NewSQL[0]. CockroachDB seems to be mimicking spanner's design principles and deliver a similar product[1].
[0] https://en.wikipedia.org/wiki/NewSQL
[1] https://github.com/cockroachdb/cockroach#design
In Thoughts on Uber’s List of Postgres LimitationsThe sql module needs other aspects of the server set up to function (e.g. the KV layer). You are free to browse the code at https://github.com/cockroachdb/cockroach if you want a more in-depth look.
In Outsmarting Go Dependencies in Testing Code(author)
This is a good insight; Live Lock was one of the things that kept me up at night, although my fellow contributors have allayed my concerns considerably.
In a write-heavy workload where the transactions follow a read-modify-write pattern, it does seem possible that your application could be facing live lock concerns. So, let's look at where those concerns come from in CockroachDB:
1. For write-write conflicts, live-lock concerns comes from the fact that a later transaction can abort your in-progress transaction if it has a priority. On top of this, if your transaction ends up aborting an earlier transaction, the other transaction may retry with a potentially higher priority, and this can result in a "priority war" of sorts.
2. "Read-write" conflicts have a worse problem: if a transaction with a later timestamp reads a key before y
Read the rest
our transaction writes to it, then your transaction always aborts. In read-modify-write workloads where the read is first, this seems to be the biggest theoretical source of live-lock.
Now, as for dealing with those issues.
+ The "Write-write" issue is the smaller concern here. The ratcheting-up of priorities is probabilistic; currently, after enough retries your transaction will have a high enough priority that it will almost certainly make progress. However, we are not totally content with this: we have an issue for our 1.0 release (https://github.com/cockroachdb/cockroach/issues/5727) to do some serious investigation of this, with some alternatives already suggested. For example, one such alternative is using "lowest original timestamp wins" to settle conflicts instead of a random priority.
+ The read-write concern seems more problematic; our read timestamp cache retains minimal data due to memory concerns, and thus aborts a bit conservatively (i.e. aborts transactions that might have been able to continue). This can be dealt with by modifying your application pattern - in particular, I would suggest using our "SNAPSHOT" isolation level for many workloads. I didn't cover this in the blog post, but in short the SNAPSHOT mode allows RW conflicts to occur without aborting transactions. SNAPSHOT transactions are subject to the "write skew" anomaly, but this anomaly does not occur if the involved transactions write to a common key. This is fortunately the case for many OLTP-type workloads, meaning SNAPSHOT can be used without anomalies; this also moves conflict-detection responsibility entirely to WW conflicts, which abort less conservatively than RW and should ameliorate any live-lock problems.
It's not a nosql database if that's what you're thinking.
https://github.com/cockroachdb/cockroach/issues/2970
In Serializable, Lockless, Distributed: Isolation in CockroachDBI should do a better job of tracking "interesting" reviews, but for now the easiest way to find some is to poke around the PRs of some open source projects that have adopted Reviewable, for example https://github.com/servo/servo/pulls, https://github.com/cockroachdb/cockroach/pulls, and https://github.com/dolphin-emu/dolphin/pulls. Each PR will have a link to the corresponding review in its description.
Let me know if you need anything else!
In Ask HN: How do you review code?Aside from everything else, it's nice to see what appears to be sane support for using TLS right there in the command line, and in the beta:
https://www.cockroachlabs.com/docs/secure-a-cluster.html
(Much thanks to Go's extensive standard library:
https://github.com/cockroachdb/cockroach/blob/master/securit... )
I've lost count on the number of projects that leaves "securing the server" as an exercise to the reader (about as useful as those error prompts that helpfully ask you to "contact the server administrator" (I AM THE ADMINISTRATOR!)).
I understand why not using TLS doesn't give an error, although I'd prefer it if it was more work to set up an insecure instance (eg: --force-no-tls --force-no-auth) -- but what cockroach does here is pretty good, and AFAIK best-in-class from those which it is natural to compare to (in all fairness, pro
Read the rest
jects like postgresql a) doesn't do too bad, and b) have a lot of legacy cruft -- the old (current) assumption is of course that if you want TLS, you'll use your secure in-house CA for everything. Which even when running Microsoft AD is in my experience way too complex for most to bother with).
Another (bad) example here is openssh, that has had decent support for certificates rather than keys for a long while now, and yet I've yet to see anyone that appear to use ssh certs in anger (Myself included, it's high up on the infinite todo-list).
One other great example of making the best of what awful tools are available for securing communications is the Caddy web server, that comes with built-in support for letsencrypt: https://caddyserver.com/
That said, while I think the docs are pretty good here, a note that leaving an unecrypted, ca-key lying around is a bad idea, might be worth a mention even in the quick-setup. At least as it stands, it's reasonably easy for someone with a working knowledge of TLS/certificates to guess which parts should be secret (all the keys) and which parts should be kept air-gapped (the ca-key).
Maybe a link to how cockroach parses/verifies certs would be nice too, for those that do have a working internal CA -- along with a little info on how/if certs integrate with authenticating nodes (eg: will my printer.example.com x509-cert allow my hacked printer to join the cluster, if it is signed by the same CA?).
Despite all the comments, I'm really liking what I see so far -- I'll be keeping an eye on this project!
The designed is compared against Spanner's several time in the interesting design doc: https://github.com/cockroachdb/cockroach/blob/master/docs/de...
In CockroachDB Skitters into BetaShowing the 15 most recent of 20 sources. Enable JavaScript to search and browse every indexed mention.