|
Interesting that you mention HA/replication, reading the article I was swept along with the pg evangelism but I fully expected at least a grudging concession to mssql on replication. We use both pg and mssql, I was surprised the article didn't mention replication. While one might be justified in describing pg as more "developer friendly", mssql is more "enterprise friendly". As a developer, I prefer pg, but as a stack designer, I still lean more toward mssql. Put another way, if I'm joining a project as a developer, I hope they're using pg, but if I'm consulting and designing a stack for a company I'll probably recommend mssql, almost definitely if they're doing something that requires replication, and/or the team isn't going to have lots of db expertise. I guess this is quite self-contradictory on one level but I think it's a fairly common view (having checked with some colleagues). I know that pg has support for replication, but it certainly isn't as easy to set up as mssql, and you need to do a LOT of reading to figure out what flavor you should use, and it's not entirely obvious what features you get with each, or which ones are really recommended and which are semi-deprecated. CTO: Do you support replication?
mssql: yes, and it's pretty easy to set up.
pg: well, we've got 3 or 4 ways of doing that, depending on what you want exactly, method A isn't really maintained any more, and method D looks like it's going to be great in a release or two, so maybe that's the one to bet on, but in the meantime you have to put up with a bit of pain. (dramatisation, probably inaccurate paraphrase, but that's what the cto heard) |
I keep wanting to switch to PG every few months because it's open source, but keep being stumped by the lack of good tooling. pgAdmin is a joke, rarely have I ever used a more unintuitive piece of software.