Not exactly. There are a few things about memcached:
a) It's a database.
b) It's fast.
c) It forces you to use decent architecture.
a) Some types of data are stored only in memcached. For example user http sessions. There are also some other information that are stored only-in-memcached, like statistics. If memcached goes down, nobody will cry. Is it the same as normal database on HDD? No. It's because records are automatically dropped after a timeout. Can you emulate this behaviour in normal DB? Yes. By periodically going through DB and removing old sessions.
b) It's really fast. You can forget about optimizing your SQL queries, you can forget about slow ORM mappings. It takes a lot of pain from you.
c) Memcached nodes doesn't grow - you can't just add more ram, you have to kill machine and destroy memcached instance before. So you have to use reasonable architecture - shared nothing on the backend side, and consistent hashing on memcached side. When a programmer understands that data shouldn't be handled on one DB box, but should be partition on many memcached nodes - it changes the way of thinking. It's a big switch, like between desktop applications - with db tied to specific app, and cloud - with db that belongs to other parts of infrastructure.
