But it could also be for legal reasons, like websites where you can post stuff for everybody to see, in case you post something highly illegal and the authorities need to find you. Another example is where a webshop is required to keep a copy of your data for their bookkeeping.

None of these require your account to “exist”. There could simply be an acknowledgement stating those reasons with “after X days the data will be deleted, and xyz will be archived for legal reasons”.

Mostly it’s 30-90 days where they keep your data, just in case somebody else decided to delete your account or you were drunk or something

This is the only valid reason. But even then this could be stated so that the user is fully aware. Then an email one week and another one day before deletion as a reminder, and a final confirmation after the fact. I’ve used services before that do this. It’s done well and appreciated.

This pseudo-deletion shadow account stuff is annoying.

What the user was doing is that they don’t trust that the system truly deleted the account, and they worry it was just deactivated (while claiming it was “deleted”). So they tried to do a password recovery which often reactivates a falsely “deleted” account.

I’ve done this before and had to message the company and have them confirm the account is entirely deleted.

Using Relational DBs where the data model is better suited to other sorts of DBs.

This is true if most or all of your data is such. But when you have only a few bits of data here and there, it’s still better to use the RDB.

For example, in a surveillance system (think Blue Iris, Zone Minder, or Shinobi) you want to use an RDB, but you’re going to have to store JSON data from alerts as well as other objects within the frame when alerts come in. Something like this:

{
  "detection":{
    "object":"person",
    "time":"2024-07-29 11:12:50.123",
    "camera":"LemmyCam",
    "coords": {
    	"x":"23",
    	"y":"100",
    	"w":"50",
    	"h":"75"
    	}
    }
  },
  "other_ojects":{
     <repeat above format multipl times>
  }
}

While it’s possible to store this in a flat format in a table. The question is why would you want to. Postgres’ JSONB datatype will store the data as efficiently as anything else, while also making it queryable. This gives you the advantage of not having to rework the the table structure if you need to expand the type of data points used in the detection software.

It definitely isn’t a solution for most things, but it’s 100% valid to use.

There’s also the consideration that you just want to store JSON data as it’s generated by whatever source without translating it in any way. Just store the actual data in it’s “raw” form. This allows you to do that also.

Edit: just to add to the example JSON, the other advantage is that it allows a variable number of objects within the array without having to accommodate it in the table. I can’t count how many times I’ve seen tables with “extra1, extra2, extra3, extra4, …” because they knew there would be extra data at some point, but no idea what it would be.

JSON data within a database is perfectly fine and has completely justified use cases. JSON is just a way to structure data. If it’s bespoke data or something that doesn’t need to be structured in a table, a JSON string can keep all that organized.

We use it for intake questionnaire data. It’s something that needs to be on file for record purposes, but it doesn’t need to be queried aside from simply being loaded with the rest of the record.

Edit: and just to add, even MS SQL/Azure SQL has the ability to both query and even index within a JSON object. Of course Postgres’ JSONB data type is far better suited for that.

Onboarding a new employee is incredibly expensive. I think the stat is that it takes on average 6 months for the company to break even for the hiring costs. That’s what I’ve read through. No idea how true it is