The CockroachDB team are doing great work no doubt, but I wish they'd stop leaning on the whole "Postgres compatible" thing.
Its not and there's no clear roadmap for it to be.
I'm not talking about obscure edge-case stuff here, I'm talking about some pretty major low-hanging fruit that is there is Postgres and not there in CockroachDB.
Anyone who thinks they can magically drop Postgres for Cockroach will be sorely disappointed.
And yes I've raised it with CockroachDB salesdroids when they've "reached out" and all I get in return is the digital equivalent of a shoulder shrug.
I often see these “I raised this to sales team… but they are not listening”. The cost of the sales team (including sales engineers) working on an opportunity is not low. If you have a use case and explain to them how you want to use their product (and if you are serious enough to buy it at the end of evaluation if it satisfies your requirements. You must also have influence in your company to make decisions. Some random startup with little cash to spend on software is not going to get you far) then they will surely try to address each of your specific issues. If not they may tell you it’s not a good use case. Just saying something about compatibility doesn’t really give them (or any Enterprise software vendor) to really hear you.
This is not to say all companies are like that but that’s how it works in general in enterprise software. Every conversation is part of a Salesforce stage (whether we like it or not)
That’s the job of sales engineer too in many cases. But a good account executive will tell you upfront if it’s not a good use case. If not you won’t buy at the end of evaluation and that has consequences for them (Companies need to predict quarterly revenues and by betting on a bad use case that person will have a bad projection of sales for that quarter or year which will ultimately be bad for them)
Expression-based indexes were added in the previous release. Partial indexes have been around for two releases. Those two combine pretty well. Temp tables exist and have existed for two years, but the implementation is not very good; they’re essentially regular tables which get cleaned up. UDFs exist in terms of enums but not records. Functions, procedures, and triggers are next up.
I would argue strongly for that. Triggers should be used rarely. If you need an update to cause some other side effect, make the whole process explicit in a stored procedure. Triggers can cause suprises and affect transactions in ways that are not always obvious.
Maybe I'm a sadist, but I love triggers. I can easily compare old and new values with them and call functions that also can do comparisons and if statements. Can I do all of this in query? Maybe, but it would look very ugly (especially if I forego the functions too). I only have one app interacting with the database, but if I had more the triggers would enforce data consistency too.
Triggers are hard to trace, I'll give you that. I try to test them pretty thoroughly via application unit tests though.
Along with the other reasons, Badger is not that great. When you have the funding and presumably the developers they have, it makes sense to do something better.
Its issue trackers. There have been sad bugs going on years deep into the project. Maybe they’re all mopped up in 2022 but I wouldn’t count on it. Its design does well on a certain usage profile at the expense of mixed read/write or other workloads. Cockroach has more money and could throw better developers (more experienced) at the problem. Haven’t looked at Pebble though.
... and the question was about why they built the key-value store instead of using an existing one. The question clearly was about pebble, not CockroachDB, so why are you arguing about what CockroachDB is?
i’m not arguing anything. there was confusion about SQL being in the title and the storage being KV. so i was trying to relay information that may advance the conversation.
Its not and there's no clear roadmap for it to be.
I'm not talking about obscure edge-case stuff here, I'm talking about some pretty major low-hanging fruit that is there is Postgres and not there in CockroachDB.
Anyone who thinks they can magically drop Postgres for Cockroach will be sorely disappointed.
And yes I've raised it with CockroachDB salesdroids when they've "reached out" and all I get in return is the digital equivalent of a shoulder shrug.