Hi, regarding number 3, I have filed https://github.com/cockroachdb/cockroach/issues/58032. Would love to get your feedback on the proposal; does it address your need? do you have a different idea for how it would work?
In Why CockroachDB and PostgreSQL Are Compatiblecockroachdb
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, 10:49:33 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
16 sourcesWe migrated a medium-to-large (in terms of model complexity, not rows), from PG to CR about a year ago. It went pretty smoothly, but you'll definetly run into issues. (Very happy overall, btw)
Every release has improved the compatibility story at an impressive rate.
The 20.2 released added partial indexes and enums, which helped close the gap in our app(though, enums don't support binary encoding yet, so might not work with your pg driver (1))
Things that are still an issue for us (all can be worked around):
1 - Can't defer foreign key checks
2 - No pg_trgm
3 - Can't tell if an upsert was an insert or an update
4 - No triggers (this is pretty huge)
(1) https://github.com/cockroachdb/cockroach/issues/57348
In Why CockroachDB and PostgreSQL Are CompatibleI'd be happy to work with you to make it happen in CockroachDB if you were so inclined :)
I added array inverted index support a little while ago in this PR: https://github.com/cockroachdb/cockroach/pull/45157
A simple full-text search engine would not be too different at the lower levels.
In Let's build a full-text search engineCool, pgtrgm has come up a few times in recent weeks. It's tracked in the below issue. I'm interested in hacking on it as it seems like a big reward for not that much work.
https://github.com/cockroachdb/cockroach/issues/41285
In A Twitch channel from which viewers can play with CockroachDBWe are held back from adoption here due to our extensive use of Postgres Triggers. Seems like the issue hasn't moved very far in a while [1] - any plans?
[1] https://github.com/cockroachdb/cockroach/issues/28296
In A Twitch channel from which viewers can play with CockroachDB[2] should be https://www.cockroachlabs.com/blog/how-we-built-a-vectorized...
Good note on the use of MVCC in Postgres. That on-access cleanup dramatically helps with the explosion of the data size and seems generally nice. Cockroach promises to keep data in a time window rather than just what's needed for concurrent operations. The user controls the time window but often people don't change it and even if they do, the build-up can be dramatic.
The sequential nature of the data storage and its implications for performance are pretty different in postgres and cockroach as I understand it. In cockroach we have fewer opportunities to exploit parallelism of write operations acting on the same "range" (a cockroach level concept for a raft group). The sequential nature of the workload is a problem not because of how the data ultimately gets lai
Read the rest
d out on disk but rather on how it gets processed and sequenced for replication. In particular, all of the writes will go to the same "range" which owns the tail of the log. Postgres, if anything, is happy with sequential workloads as they touch the fewest interior blocks of the B+-Tree.
Cockroach effectively can't offload the work of GC (as we call it) to foreground or already existing tasks mainly because it mains maintaining consistency stats between replicas hard. See an attempt here: https://github.com/cockroachdb/cockroach/pull/42514.
Thanks for the kind words. We're working on it.
1a) (as you noted) should be in the next release
1b) working on it, should be in the next release: https://github.com/cockroachdb/cockroach/pull/50320
1c) I filed https://github.com/cockroachdb/cockroach/issues/50418 to track. It seems plausible that we could fit in a story here with the work we're doing to expose MVCC timestamps to SQL.
1d) No plans on any sort of text search story but geo is underway (see https://github.com/cockroachdb/cockroach/issues?q=is%3Aissue...)
Curious to hear about your use of full text search in postgres.
Have you ever used pgtrgm? Would something like that or compatible with that be interesting to you? https://www.postgresql.org/docs/12/pgtrgm.html
For "even their enterprise backup capabilities are poor." are there specific things you have in mind?
In A Twitch channel from which viewers can play with CockroachDBI'm not sure that there's a simple answer here. One place where people often run in to trouble is that they deploy cockroach with a global topology and then are surprised when things are much, much slower than in postgres. I'm going to assume that you're only talking about a single-region deployment.
One place cockroach radically differs from postgres is that it stores historical versions of rows and it stores them sequentially. This means that if you have an update-heavy workload and you do not lower your GC TTL for that data, you can see dramatic performance degradation that you would not see with postgres (see [1]).
I suspect that there are some cases where our optimizer will not make the same or as good of choices as postgres, especially in cases of joins across large numbers of tables. Our optimization of CTEs is relatively primitive
Read the rest
compared to PG IIRC.
Another place where we do quite poorly that doesn't come up in production but commonly comes up in testing are schema changes. Cockroach schema changes are online and do not block concurrent writes. That being said, they require coordination and phases. Running schema changes in tight loops will yield relatively low throughput and performance deteriorates given some of the coordination is a function of the total number of schema elements. This almost always comes up in the context of testing things like ORMs where schema elements are created and destroyed in every test. I doubt this is the sort of thing you're looking for but it's definitely a thing that comes up.
As noted in the hash-sharded index post, cockroach is not well suited to scale write traffic incident on a single key. In these cases the in-memory, local synchronization of postgres is likely going to be more efficient. Sequential workloads suffer from a similar problem that doesn't exist in postgres. In fact, sequential workloads are quite well suited to their B+-Tree. That being said, this comes up relatively infrequently and when it does we have tools to mitigate it.
Our temp table implementation likely violates people's intuition. It primarily exists for compatibility to enable a broader suite of testing. Temp tables are as expensive as regular tables.
In general some of our data-intensive queries are going to be less efficient due partially the efficiency of our execution engine, partially to the efficiency of our KV, and partially due to the fact that the KV is implemented in a distributed way requiring a certain amount of data copying and synchronization whereas postgres can get by just passing pointers around in memory. I suspect its ability to achieve access locality for some workloads is immense and leads to wins. We have done a lot of work recently to "vectorize" our execution engine and make it more efficient (see [2]) and are in the process of replacing our storage engine, in some small part to eventually improve our scan speed (see [3]) and more generally improve our efficiency.
Maybe other can chime in but in my experience there isn't so much a general class of queries where we're orders of magnitude slower than postgres. Often when people see orders of magnitude differences it has to do with index selection in a plan for a specific query but this tends not to be a generalized problem and we're pretty active about rectifying these reported problems. We've also been focusing on adding tools to better understand query plans and performance.
More often it's the case that on a per-core basis, cockroach is less efficient in terms of throughput than a single instance of postgres but in return for that you get a number of benefits, one of which being that you can scale the thing with your load. If you're looking to optimize $/query in a high-throughput setting and don't care about the HA or other properties, cockroach probably isn't the answer. Often when you're trying to run a cost-optimized $/query system, it's because the scale is very large so postgres might not be the answer either. It may make a lot of sense if it's a very update-heavy workload where the total data set size is small.
Hope that was helpful. Maybe other who have had experience with cockroach and found it to be pathologically slower in some cases can chime in. We'd also love to hear about those cases in https://github.com/cockroachdb/cockroach/issues.
[1] https://github.com/cockroachdb/cockroach/issues/17229
[2] https://www.cockroachlabs.com/blog/how-we-built-a-vectorized...
1. Yes.
2. No, you just loose the ability to rollback to an arbitrary position in that window. It might also be more expensive to re-start, but it's been a few months since I looked at the code.
3. I am aware of multi-column-families not working (but that should get tackled?): https://github.com/cockroachdb/cockroach/issues/28667
I know PG is easier in that respect, but the performance ceiling is much lower.
In Nested Transactions in CockroachDB 20.1No, there isn't.
The only option is the dump command (full backup). But it's slow. And the restore is unreasonably slow. If you have a medium-sized database, you'll likely have to accept uncomfortably large (possibly even disastrous) data-loss window and a long downtime while you restore.
There's even cases where it can't work (1).
The free options from PG (namely things like barman and the built-in replication) is far superior to what the paid version of CockroachDB offers, let alone the community edition.
I wish they'd let you take a rocksdb checkpoint of a single node and restore that into another cluster. This should work if your replica == node count (a common setup). Getting access to the checkpoint isn't complicated, but recovering this with the leaseholders and cluster config baked into the database requires more insight into thei
Read the rest
r abstractions than I have. Feels like something they need anyways, because, as-is, a permanent loss of 2 nodes is impossible to recover from (2)
(1) https://github.com/cockroachdb/cockroach/issues/28948
(2) https://github.com/cockroachdb/cockroach/issues/17186
We recently migrated a few small systems to CockroachDB (as a stepping stone). Overall, the experience was positive. The hassle free HA is a huge peace of mind.
I know people say this is easy to do in PG. I have recently setup 2ndQuadrant's pglogical for another system. That was also easy (though the documentation was pretty bad). The end result is quite different though and CockroachDB is just simpler to reason about and manage and, I think, more generally applicable.
But, on top of the well-documented postgresql incompatibilities, we have run into other issues.
First, and probably the reason you should stay away from CockroachDB's community edition, is the poor story around backups. You only get full backups. They are very slow to take and very slow to restore. There are even cases where it can fail to backup (https://github.com/cockroa
Read the rest
chdb/cockroach/issues/28948).
There are a lot of little bugs, which isn't a huge deal, but it's hard to find and you can spend a lot of time looking into it. Just yesterday we noticed that queries that use now() can't use indexes. Searching github's thousands of issues for "now() index performance" I get ~500 hits. Thankfully they are fast to respond to questions on slack / forums. But they _really_ need to clean up the hundreds (thousands?) of little bugs - some of them have been around for years. Most of them are near-non-issues, except for the time you waste looking into it.
Finally, performance seems worse than it could be. Running in single-node-mode with an _in memory_ database (for our integration tests) is still slower than postgresql. Restoring a 150mb dump file (just a bunch of inserts) takes over 2 minutes. But it's more than fine for the CRUD kind of thing we're doing.
You can check out how CockroachDB uses special error symbols with goyacc to provide good error messages for SQL passing. It’s a very interesting read really.
https://github.com/cockroachdb/cockroach/tree/master/pkg/sql...
In Why not to use (f)lex, yacc or bisonI have no idea what you're saying. What's a "row-oriented storage" if not storing all the column values of a row in sequence, in contrast to storing all the values in a column across the table in sequence (aka "column store"). What does the fact that it's exposed behind a KV interface have to do with anything? What's "more" about Postgres' "row-orientedness" compare to MySQL?
In case you didn't know, a row [idA, valA, valB, valC] is not stored as [idA: [valA, valB, valC]]. It's more [id/colA: valA, id/colB: valB, id/colC: valC] (modulo caveats around what we call column families[0], where you can have it be more like option (a) if you want). My explanation here is pretty bad, but [1][2] go into more details.
[0]: https://www.cockroachlabs.com/docs/stable/column-families.ht...
[1]: https://www.cockroachlabs.com/blog/sql-in-cockroachdb-mapp
Read the rest
Our goal is to make switching over from PostgreSQL easy. For Ecto in particular, we have a tracking issue that shows the items in our backlog that would improve compatibility: https://github.com/cockroachdb/cockroach/issues/33441
In Migrating to CockroachDBIt was fixed in CRDB also: https://github.com/cockroachdb/cockroach/issues/42942
In Migrating to CockroachDBShowing the 15 most recent of 16 sources. Enable JavaScript to search and browse every indexed mention.