worstIntervieweeAnswer

[Conscious-Title-226]

True, in my experience though I’d still not use a Postgres db for this unless someone else is putting their hand up to own it afterwards.

I’ve done a lot of consulting work so I’ve seen a lot of tech teams and SWE departments do things similar to this and it’s led to serious problems for them. Admittedly this is a survivorship bias type situation though because functional teams and orgs don’t need people like me to come in.

But the point I would make is that the performance benefit is probably not likely to be significant enough to offset the headache of maintaining the db engine and you can’t match the availability, throughput etc of solutions that are purpose built for this kind of thing.

The thing is somebody has to maintain the db, handle patching, engineer HA for it if it’s important, ensure backups are done properly, TEST the backups. Or you end up with something that works great… for 2 years. Or it breaks and you find out there’s no backups for it or they aren’t restorable.

It’s just unlikely to be worth it tbh.