What is Memcached and what are its top alternatives?
Top Alternatives to Memcached
Redis
Redis is an open source, BSD licensed, advanced key-value store. It is often referred to as a data structure server since keys can contain strings, hashes, lists, sets and sorted sets. ...
Ehcache
Ehcache is an open source, standards-based cache for boosting performance, offloading your database, and simplifying scalability. It's the most widely-used Java-based cache because it's robust, proven, and full-featured. Ehcache scales from in-process, with one or more nodes, all the way to mixed in-process/out-of-process configurations with terabyte-sized caches. ...
Varnish
Varnish Cache is a web application accelerator also known as a caching HTTP reverse proxy. You install it in front of any server that speaks HTTP and configure it to cache the contents. Varnish Cache is really, really fast. It typically speeds up delivery with a factor of 300 - 1000x, depending on your architecture. ...
Hazelcast
With its various distributed data structures, distributed caching capabilities, elastic nature, memcache support, integration with Spring and Hibernate and more importantly with so many happy users, Hazelcast is feature-rich, enterprise-ready and developer-friendly in-memory data grid solution. ...
MongoDB
MongoDB stores data in JSON-like documents that can vary in structure, offering a dynamic, flexible schema. MongoDB was also designed for high availability and scalability, with built-in replication and auto-sharding. ...
Couchbase
Developed as an alternative to traditionally inflexible SQL databases, the Couchbase NoSQL database is built on an open source foundation and architected to help developers solve real-world problems and meet high scalability demands. ...
Memcached Cloud
Memcached Cloud is a fully-managed service for running your Memcached in a reliable and fail-safe manner. Your dataset is constantly replicated, so if a node fails, an auto-switchover mechanism guarantees data is served without interruption. Memcached Cloud provides various data persistence options as well as remote backups for disaster recovery purposes. ...
etcd
etcd is a distributed key value store that provides a reliable way to store data across a cluster of machines. It’s open-source and available on GitHub. etcd gracefully handles master elections during network partitions and will tolerate machine failure, including the master. ...
Memcached alternatives & related posts
- Performance875
- Super fast535
- Ease of use510
- In-memory cache442
- Advanced key-value cache321
- Open source189
- Easy to deploy179
- Stable163
- Free152
- Fast120
- High-Performance39
- High Availability38
- Data Structures34
- Very Scalable32
- Replication23
- Great community20
- Pub/Sub19
- "NoSQL" key-value data store17
- Hashes14
- Sets12
- Sorted Sets10
- Lists9
- BSD licensed8
- NoSQL8
- Async replication7
- Integrates super easy with Sidekiq for Rails background7
- Bitmaps7
- Open Source6
- Keys with a limited time-to-live6
- Strings5
- Lua scripting5
- Awesomeness for Free!4
- Hyperloglogs4
- outstanding performance3
- Runs server side LUA3
- Networked3
- LRU eviction of keys3
- Written in ANSI C3
- Feature Rich3
- Transactions3
- Data structure server2
- Performance & ease of use2
- Existing Laravel Integration1
- Automatic failover1
- Easy to use1
- Object [key/value] size each 500 MB1
- Simple1
- Channels concept1
- Scalable1
- Temporarily kept on disk1
- Dont save data if no subscribers are found1
- Jk0
- Cannot query objects directly11
- No WAL1
- No secondary indexes for non-numeric data types1
related Redis posts
We use MongoDB as our primary #datastore. Mongo's approach to replica sets enables some fantastic patterns for operations like maintenance, backups, and #ETL.
As we pull #microservices from our #monolith, we are taking the opportunity to build them with their own datastores using PostgreSQL. We also use Redis to cache data we’d never store permanently, and to rate-limit our requests to partners’ APIs (like GitHub).
When we’re dealing with large blobs of immutable data (logs, artifacts, and test results), we store them in Amazon S3. We handle any side-effects of S3’s eventual consistency model within our own code. This ensures that we deal with user requests correctly while writes are in process.
















I'm working as one of the engineering leads in RunaHR. As our platform is a Saas, we thought It'd be good to have an API (We chose Ruby and Rails for this) and a SPA (built with React and Redux ) connected. We started the SPA with Create React App since It's pretty easy to start.
We use Jest as the testing framework and react-testing-library to test React components. In Rails we make tests using RSpec.
Our main database is PostgreSQL, but we also use MongoDB to store some type of data. We started to use Redis  for cache and other time sensitive operations.
We have a couple of extra projects: One is an Employee app built with React Native and the other is an internal back office dashboard built with Next.js for the client and Python in the backend side.
Since we have different frontend apps we have found useful to have Bit to document visual components and utils in JavaScript.
- Way Faster than Redis and Elasticache Redis1
- Easy setup1
- Simpler to run in testing environment1
- Container doesn't have to be running for local tests1
related Ehcache posts
- High-performance102
- Very Fast66
- Very Stable56
- Very Robust43
- HTTP reverse proxy36
- Open Source20
- Web application accelerator17
- Easy to config10
- Widely Used4
- Great community3
- Essential software for HTTP1
related Varnish posts
We're using Git through GitHub for public repositories and GitLab for our private repositories due to its easy to use features. Docker and Kubernetes are a must have for our highly scalable infrastructure complimented by HAProxy with Varnish in front of it. We are using a lot of npm and Visual Studio Code in our development sessions.











Around the time of their Series A, Pinterest’s stack included Python and Django, with Tornado and Node.js as web servers. Memcached / Membase and Redis handled caching, with RabbitMQ handling queueing. Nginx, HAproxy and Varnish managed static-delivery and load-balancing, with persistent data storage handled by MySQL.
- High Availibility9
- Distributed Locking6
- Distributed compute5
- Sharding5
- Load balancing4
- Map-reduce functionality3
- Publish-subscribe3
- Sql query support in cluster wide3
- Written in java. runs on jvm2
- Simple-to-use2
- Multiple client language support2
- Rest interface2
- Optimis locking for map2
- Easy to use1
- Performance1
- Super Fast1
- Admin Interface (Management Center)1
- Better Documentation1
- License needed for SSL3
related Hazelcast posts
- Document-oriented storage822
- No sql585
- Ease of use544
- Fast462
- High performance404
- Free251
- Open source212
- Flexible177
- Replication & high availability139
- Easy to maintain107
- Querying39
- Easy scalability35
- Auto-sharding34
- High availability33
- Map/reduce29
- Document database26
- Easy setup24
- Full index support24
- Reliable15
- Fast in-place updates14
- Agile programming, flexible, fast13
- No database migrations11
- Enterprise7
- Easy integration with Node.Js7
- Enterprise Support5
- Great NoSQL DB4
- Aggregation Framework3
- Drivers support is good3
- Support for many languages through different drivers3
- Schemaless2
- Managed service2
- Easy to Scale2
- Fast2
- Awesome2
- Consistent1
- Very slowly for connected models that require joins5
- Not acid compliant3
- Proprietary query language1
related MongoDB posts









Recently we were looking at a few robust and cost-effective ways of replicating the data that resides in our production MongoDB to a PostgreSQL database for data warehousing and business intelligence.
We set ourselves the following criteria for the optimal tool that would do this job: - The data replication must be near real-time, yet it should NOT impact the production database - The data replication must be horizontally scalable (based on the load), asynchronous & crash-resilient
Based on the above criteria, we selected the following tools to perform the end to end data replication:
We chose MongoDB Stitch for picking up the changes in the source database. It is the serverless platform from MongoDB. One of the services offered by MongoDB Stitch is Stitch Triggers. Using stitch triggers, you can execute a serverless function (in Node.js) in real time in response to changes in the database. When there are a lot of database changes, Stitch automatically "feeds forward" these changes through an asynchronous queue.
We chose Amazon SQS as the pipe / message backbone for communicating the changes from MongoDB to our own replication service. Interestingly enough, MongoDB stitch offers integration with AWS services.
In the Node.js function, we wrote minimal functionality to communicate the database changes (insert / update / delete / replace) to Amazon SQS.
Next we wrote a minimal micro-service in Python to listen to the message events on SQS, pickup the data payload & mirror the DB changes on to the target Data warehouse. We implemented source data to target data translation by modelling target table structures through SQLAlchemy . We deployed this micro-service as AWS Lambda with Zappa. With Zappa, deploying your services as event-driven & horizontally scalable Lambda service is dumb-easy.
In the end, we got to implement a highly scalable near realtime Change Data Replication service that "works" and deployed to production in a matter of few days!
We use MongoDB as our primary #datastore. Mongo's approach to replica sets enables some fantastic patterns for operations like maintenance, backups, and #ETL.
As we pull #microservices from our #monolith, we are taking the opportunity to build them with their own datastores using PostgreSQL. We also use Redis to cache data we’d never store permanently, and to rate-limit our requests to partners’ APIs (like GitHub).
When we’re dealing with large blobs of immutable data (logs, artifacts, and test results), we store them in Amazon S3. We handle any side-effects of S3’s eventual consistency model within our own code. This ensures that we deal with user requests correctly while writes are in process.
- High performance18
- Flexible data model, easy scalability, extremely fast17
- Mobile app support8
- You can query it with Ansi-92 SQL6
- All nodes can be read/write5
- Open source, community and enterprise editions4
- Local cache capability4
- Both a key-value store and document (JSON) db4
- Equal nodes in cluster, allowing fast, flexible changes4
- Automatic configuration of sharding3
- SDKs in popular programming languages3
- Elasticsearch connector3
- Easy setup3
- Web based management, query and monitoring panel3
- Linearly scalable, useful to large number of tps3
- Easy cluster administration3
- Cross data center replication3
- NoSQL2
- DBaaS available2
- Map reduce views2
- FTS + SQL together1
- Terrible query language3
related Couchbase posts
We implemented our first large scale EPR application from naologic.com using CouchDB .
Very fast, replication works great, doesn't consume much RAM, queries are blazing fast but we found a problem: the queries were very hard to write, it took a long time to figure out the API, we had to go and write our own @nodejs library to make it work properly.
It lost most of its support. Since then, we migrated to Couchbase and the learning curve was steep but all worth it. Memcached indexing out of the box, full text search works great.
If you want to use Pouchdb might as well use RxDB which is an observables wrapper for Pouch but much more comfortable to use. Realm is awesome but Pouchdb and RxDB give you more control. You can use Couchbase (recommended) or CouchDB to enable 2-way sync
Memcached Cloud
- High-availability6
- Heroku add-on6
- Fast3
- Email alerts2
- Fail-safe2
- 24/7 monitoring & support1
- Backups and import1
- Offered by Redis Labs1
- Auto-switchover1
- Seamless scalability1
related Memcached Cloud posts
etcd
- Service discovery11
- Fault tolerant key value store6
- Bundled with coreos2
- Secure1
- Open Source1
- Privilege Access Management1
- Consol integration1