What is the best and most safest way to handle PHP sessions. Is the best way to store sessions in:

  1. Database (more reliable, but high bottleneck, slow speed, not good for high database usage websites)?

  2. Memcache (super fast, but distributed more security problems, chances of loosing data when the server restarted and chances of loosing data when the cache is full)?

  3. Files (default option, I guess slow since it reads and writes from file I/O, less security, etc).

Which method is the best? What are the problems and good things of each of those approaches?

  • 2
    I believe you should specify if you're using only one machine, or if the application is distributed, since it will heavily influence the answers. Nov 5, 2012 at 9:00
  • 1
    @haylem this is the most appropriate place to ask this question, its not programming question its programming conceptual problem, Nov 13, 2012 at 23:28
  • 3
    This is really a poor question because 'best' depends on your specific circumstance. The 'best' for Facebook is probably not the same 'best' for your personal home page. Nov 14, 2012 at 4:22
  • 1
    @GrandmasterB i know that thats why i clearly asked "What are the problems and good things of each of those approaches?" to find out which one is the best for me. Nov 14, 2012 at 7:52

7 Answers 7


The best is to store at Memcached as we can easily resolve the other issues (cache size, security, etc.)

facebook is the #1 consumer of memcached. Please read if interested: http://www.facebook.com/note.php?note_id=39391378919

How to resolve the other issues?


What about using the MEMORY storage engine in MySQL?

It is not as fast as Memcache but has the advantage that you can use plain SQL, and you can also use the normal storage engine when it will not be needed and switch to MEMORY when the number of users/requests grows.

I'm using it for storing large amounts of statistical data in a web app which changes frequently so it is not used for handling sessions but I think it should be well suited for this purpose.


For the vast majority of day-to-day applications, keeping sessions in databases is fine. The volume & level of concurrency that a sql server can handle will be more than sufficient. The key is to keep each entry small in size and purge the unneeded rows with regularity. And proper indexing, of course.

The file system - I've never seen the need to do that. I prefer the simplicity of managing rows in tables rather than thousands of little files. Plus you cant query across files if you want to dig into session statistics.

Keep in mind, with PHP, its easy to swap out session handlers. So you can start with one storage format, and migrate to another without too much hassle.


This blog post shows the results of a performance comparison of different session storage engines with Magento and they seem to have concluded that up to about 75 concurrent users there isn't really a performance difference between them.

I think that at these levels (they had about 5 transactions a second, which would be about 430k hits over a 12 hour period) the overhead in everything else dominates the performance numbers you see since file/DB/Memcache/Redis will all happily handle the traffic without breaking a sweat if used properly.

That leaves other factors such as scalability, reliability and security.

I'd first like to say that anything that compromises your file storage will also likely compromise anything else since an attacker can then just modify your application code or at the very least discover keys and storage access protocols/credentials even if they have read-only access. File storage will work well for a low volume site, is easy to set up and is easy to reason about. As much as you say you hit the disk, a DB read will also hit disk and if the DB can cache it, your OS will also likely have cached the session file. Also, its one file read, and your file system is brilliant at getting to it if you already know its name. If you're using PHP, do you know how many file reads the system has to do just to serve your application? The downside is that you can't go too far as you will quickly reach the limit of the number of files you can keep on a single disk.

Memcache is relatively fast and if you're considering Memcache class solutions more broadly (Redis, etc) there are some that will even promise persistence with in memory reads for speed so you get the most of both worlds. They are also relatively simple to reason about and the key-value nature of sessions is exactly what these have been designed to do. Do you know how much you would have to put into a session to fill one of these up? Either, way, all of your options will force you to compromise if you reach their capacity. Disks fill up with files (number and size factor in here), cache stores fill up in capacity and databases have limited numbers of rows and the same disk capacity limits as the file approach. Also, these systems are only distributed if you run them in a distributed fashion. Most work just fine with a single server setup. If you distribute them then you probably already have distributed web servers / database servers etc so your distributed system problems certainly won't be appearing from your session storage choice. However, when you want 10x the traffic/capacity etc, getting there is much more natural with this than it is with the file storage scheme. Some key/value stores will also allow you to conduct simple analyses of the session data relatively easily but most won't get you anywhere near what SQL can do.

I'm not sure why you propose that database may be more reliable than the other options, but I get the appeal of the database since your PHP application probably already makes use of it. This means you don't add another server dependency and you can probably reuse the same connection you use to fetch session data to get user data so you don't have to establish one for data, one for Memcache, etc. If you index the table well, it will also perform reasonably fast and provides pretty simple semantics you already familiar with for reaping old sessions or even analyzing session data (I'm not sure why you would want to and if you aren't either, this probably doesn't matter so much). Scaling to massive scales isn't as trivial as with something like Redis, but going from one PHP server to two both accessing the same DB is pretty simple.

I think this choice isn't so important in the beginning. Each approach has challenges and advantages and things you have to think about. Generally speaking, you can probably get away with just using the defaults of PHP/whatever framework you use or even just the easiest thing to get going with. If the choice turns out to be bad later on, your performance analytics will tell you and you will be armed with the data you need to make the appropriate choices given the specific nature of the traffic you get. Up front, all you can reasonably have is general speculation.


It depends on your needs.

There are some differences between files and database storage. See this question.

However, you can do what's done in Rails 3 by default, and use only encrypted cookies for your session. So you encrypt all values in a way that only you can decrypt it later (e.g. private/public keys), and you let the client do the state keeping for you.

On the one hand it limits you to 4Kb, which is actually usually enough (since you usually want to store IDs, not whole objects), but the really nice benefit you get is that you don't need to worry about session cleanup. You leave that up to the client, where it actually should be.

  • 2
    Unless you've separated out your static resources to be outside your cookie path, cookies are a fixed tax you have to pay on every request. Nov 5, 2012 at 8:36
  • jQuery and Bootstrap are around 150kb combined, and that's without other libraries. Cookie max is 4kb, and usually below 1Kb. Unless the OP is asking about extreme circumstances - who cares about that kind of taxation? Nov 5, 2012 at 17:14
  • @YamMarcovic there are few problems 1) cookies are going to server too (users usually have faster download then upload) 2) usually pages have 100's of requests for static files (images,js,css) so it can get into 100kb on each request going up Nov 11, 2012 at 18:18
  • @MiroSvrtan If you're making your users send hundreds of requests per page (where did that ever happen?), optimization is clearly not an issue for you. Nov 11, 2012 at 20:48
  • I had a client whose site was making ~170 HTTP requests to load the front page before consulting me for speed optimizations, so it happens, trust me. Btw, private/public keys are a concept from asymmetric cryptography, which would generally not be applied in this scenario where its equivalent to a symmetric cipher, only more complex to implement. Also, most session storage implementations rely on some cookie managed by the client, so the benefit described in the last paragraph of the answer applies to all of them.
    – jeteon
    Dec 1, 2015 at 15:31

For my particular situation, I can tell you that sessions in a database is the number one cause of our server hang-ups by a good margin. our sessions table gets corrupted frequently enough that we have taken to truncating it pre-emptively.

memcache sounds attractive, but we have too many processes that clear the entire memcache, so user sessions would be cut off too frequently. and the older sessions would be cleared as memory became full... so no more permanent logins.

We'll be trying the default file-based sessions soon.

If you are worried about security of your session data, then you shouldn't put that data in the session - and don't trust the session - validate the user on every request.


You can try to save your session on Redis. Redis is fast like Memcached but also has several data-persistence options. In addition, various PHP clients are supported.

In addition, you can try 3rd party services like the Memcached Cloud that has built-in replication and storage engine capabilities

Disclosure, I'm Co-Founder and CTO of Garantia Data.

  • 2
    Thanks for the disclosure! Do make sure that you participate on this site beyond posts where you can mention your own products though, we want you as a person to contribute, not your company. Nov 18, 2012 at 13:40

Not the answer you're looking for? Browse other questions tagged or ask your own question.