|
MSSQL has some problems, some of which the post talks about. However, I tried pg out, planned to use it instead of MSSQL. 1. HA, via replication, clustering, etc. are all fantastic as well as easy and trivial to setup. Once PG can offer a simple little wizard and setup replication, or shared-nothing clustering with automatic fail over, awesome. Or even tx log shipping with a few clicks. Instead, last I tried (9.0 I think), pg drops you off with some weird system that makes you run shell as a specific user, where you run generic sounding commands. Oh and some default config that seemingly has some bad defaults you probably should change. 2. Overall, MSSQL makes it easy to run a DB. I was doing a billion transactions a day (each which wrote to a few tables and also included a real ACID balance update), and I didn't need a full time DBA or have to have particularly awesome experience beforehand. With pg, I sorta got somewhere, but I had little confidence 3. Development is far superior on MSSQL. Supporting other languages is a null point, because they aren't running as part of the query execution engine. That is, there's no real difference in using Python inside PG versus an external client, as far as I could tell. You still had to submit queries and make a transition. So TSQL seemed far nicer to work with than plpgsql. Although, the record types in pg were much nicer I'll admit. Another annoyance: pg didn't offer multiple returnsets in many situations. This made it awkward to run a sub function that needed to return results from different tables as separate queries. And the perf tools and UI was just so, so much better. 4. There'd be strange "little" features you'd just expect to be there, like materialized views, which pg simply does not have. Pg still lacks materialized views. The current implementation is essentially pointless, as it doesn't update the view automatically. I'm very much for PG, and believe it's an important project and am trying to use it for future development. Much because Microsoft went back on its word that it wouldn't move to an Oracle-style licensing where you pay for CPU power instead of just sockets. They've also made questionable decisions with Enterprise vs Standard, putting extra cumbersome limitations. They aren't adding features like JSON or arrays quickly. And also, I think it's important to run open source and try to make sure free systems stay viable. But MSSQL has a lot going for it, and the ease of use and built in HA options don't even seem like goals for PG. If licensing weren't in the way, and I just wanted an easy system that was capable but didn't require lots of time, MSSQL makes a strong choice. |
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)