Thread: Using unlogged tables for web sessions
Hello. I was wondering if anyone was using unlogged tables for website sessions in production. I'm interested if it breaks the prevailing opinion that you don't put sessions in PG.
Stephen Carboni <stephen.entropy@gmail.com> writes: > Hello. > > I was wondering if anyone was using unlogged tables for website > sessions in production. I'm interested if it breaks the prevailing > opinion that you don't put sessions in PG. This really depends on what you define as website session data and what benefit you would see compared to the additional overhead of maintaining this session information remotely (from the client). Depending on your application, there is often some session information which makes more sense stored on the back end server rather than in the client - notably, data used by your server API to modify responses or possibly encrypted data to handle 'remember me' type functionality. However, you probably don't want to store session data used by the client API e.g. browser Javascript as this would introduce additional network overheads, latency, load on web and db server, increased web and db server API complexity and possibly additional data privacy/security concerns you will need to manage. This can be hard to justify when you have good client data storage facilities available. I have not come across a use case where it made sense to store ALL session data remotely in the database. I have seen situations with a very specialised application where having a more full featured LOCAL (to the client) database server to record session information can be useful, but this is rare. -- Tim Cross
On 16/04/2020 19:39, Stephen Carboni wrote: > Hello. > > I was wondering if anyone was using unlogged tables for website > sessions in production. I'm interested if it breaks the prevailing > opinion that you don't put sessions in PG. I generally put sessions in postgresql, with regular tables, when I'm using persistent server-side sessions, rather than just stashing all the user data in a signed cookie or local storage. It ... works fine? It drastically simplifies app deployment to have a single point of persistent storage, and having one that you can easily interrogate by hand simplifies development and debugging. Reads are a single indexed query, writes are typically HOT, so the IO and overhead aren't drastically different from any other persistent store. A lot of webapp development advice is based on "Ah, but how will you scale it up to Facebook levels of traffic?" and then skipping over the answer "Um, I won't ever need to. And if I did I'd have enough revenue to hire someone very, very good to rearchitect my session storage.". Cheers, Steve
> On Apr 16, 2020, at 1:39 PM, Stephen Carboni <stephen.entropy@gmail.com> wrote: > > I was wondering if anyone was using unlogged tables for website > sessions in production. I'm interested if it breaks the prevailing > opinion that you don't put sessions in PG. Popular CMS systems like Drupal use the database for web sessions. Probably only logged tables unless you did some extracustomization of the installation. I'm not aware of any issues with it performance or otherwise. John DeSoi, Ph.D.