CockroachDB vs Memcached: What are the differences?
CockroachDB: A cloud-native SQL database for building global, scalable cloud services that survive disasters. Cockroach Labs is the company building CockroachDB, an open source, survivable, strongly consistent, scale-out SQL database; Memcached: High-performance, distributed memory object caching system. Memcached is an in-memory key-value store for small chunks of arbitrary data (strings, objects) from results of database calls, API calls, or page rendering.
CockroachDB and Memcached can be primarily classified as "Databases" tools.
Memcached is an open source tool with 9K GitHub stars and 2.6K GitHub forks. Here's a link to Memcached's open source repository on GitHub.
According to the StackShare community, Memcached has a broader approval, being mentioned in 755 company stacks & 267 developers stacks; compared to CockroachDB, which is listed in 13 company stacks and 8 developer stacks.
This was roughly 4 years ago at this point. We had been using an old iteration of memcache on Windows as the data cache per server for while and had for whatever reason opted to store our session data (to which the application is heavily dependent) in App Fabric. App Fabric had come to EOL and we needed to move away from it. As a quick search showed throughput capacity to be higher and overall features of Redis were better we initially implemented it. The number of changes required were minimal and we were able to migrate away to a more resilient system pretty quickly. We hit a snag in that the implementation of the Redis session handler at that point only took a single IP so we had to do use keepalived and HAProxy to display the application consistently between master and slave failovers. This caused issues on occasion of dropped connections to the backend service. We upgraded our client and could put both members into our config files and it stopped timing out. We were all happy in this and it was (for it's own part) a significant upgrade. Generally performance was better for all pages. We found however, that our application was serializing all requests and locking on the thread via session lock for a great many things and this caused us and our users considerable headaches on occasion. We found that the implementation of the couchbase session handler gave us the option of ignoring session write locks and not be required to rewrite dozens of pages to handle the no session requirement as the application was working fine without the need to be threadsafe. Though the maximum throughput was not as good compared to Redis the application performance was considerably better as a result of the change. The multi-master write was a big benefit and the cross data center replication was a nice thing to have as that would allow our users to remain logged in even across DataCenter fail-over events (praying that never happened). Overall we used that for session handling and chose to use couchbase (in a 2nd cluster) to handle memcache requests as that gave us greater capacity to handle larger objects more efficiently. We are, all these years later, looking to move into the newer features of couchbase to give us more and better use of this product that really has been the answer to a bunch of the growing pains we experienced. Since the decision performance has not been on wild rides and stability has never been better. So I sing the praises of couchbase to anyone that will listen.
Sign up to add or upvote prosMake informed product decisions
Sign up to add or upvote consMake informed product decisions
What is CockroachDB?
What is Memcached?
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions