You are assuming that session storage and database storage are exclusive. They aren't. But let's start by assuming they are.
The advantage to session storage is three-fold:
- No need to explicitly insert data into the database. You just simply set a session variable and you're done. Simple and low-risk functionally.
- No need to manage the lifecycle of a user visit and shopping cart as containers / frameworks do it for you
- Usually auto-cleanup of old idle sessions is done for you.
Disadvantages of session storage:
- Session affinity, unless you investigate replication
- No failover, unless you investigate replication or manual persistence of session state to disk, which can get complicated.
- All sessions must be stored in memory. This is amplified if you employ replication.
Advantages of database storage:
- No need to worry about session affinity or state replication. You can round-robin all requests.
- Less memory overhead in application.
- If the order is completed, everything ends up in the database anyway, so this could make completion easy because the data is already present.
Disadvantages of database storage:
- Abandoned carts - some anonymous user added an item to their shopping cart and disappeared. That data sticks around forever unless you have some sort of expiration process.
- You need to come up with a way to track users and figure out if, for a given request, this represents an existing or new browsing session. (yes, this is probably easy if you use a cookie, but how do you ensure two users don't end up with the same id?).
- More code
You didn't mention what platform you are using. I would seek an approach that uses a database-backed session where the session data only exists in memory during the life of a request/response cycle, loading it from the database and saving back to the database. This has served me well in the past.
Advantages of a database-backed session:
- No need for server affinity.
- Easy on the app server memory
- Idle / abandoned session data is cleaned up for you.
- Lifecycle of user first visit, repeat visit, session end is all figured out for you.
- Easy to code
Disadvantages of a database-backed session:
- Configuration - you need to investigate your container, whether it's PHP, Java EE (Tomcat, Jetty, JBoss, etc.), node.js + express.js or whatnot support this and supply the right configuration.
- You may need to load test this since you are adding 2 database operations per request.
There is a third possibility, which somebody touched on earlier. You could skip the use of sessions altogether and use client-side storage by either embedding everything in a cookie or html local storage.
I'll leave the pros/cons of that as an exercise to you, but I'll give you a hint that for html5 storage, browser compatibility may be something to review carefully.
I've outlined the facts for you. Hopefully this helps you make the right decision for your situation.