PostgreSQL vs. SQL Server from the point of view of a data analyst (2014)
pg-versus-ms.com
pg-versus-ms.com
- Management Studio is superior to any standard query manager ive found for PG. I currently use what is in intellij (which is similar to their datagrip product) which I find perfectly acceptable and in some ways superior to Management Studio, but PGAdmin isn't in the same ballpark.
- MSSQL visual query explainer is great - ive found some alternatives (http://tatiyants.com/pev/#/plans) and in general ive gotten much better at reading and understanding the text output of PG's explain, but I do miss MSSQL in this regard.
- MSSQL CTE's not being optimization fences meant that I got to use them in more places. But I can do more things with CTE's in PG (such as using an ORDER BY) - this is relatively minor but annoying - readability with CTE's vs subqueries is much improved.
- Snapshot and transaction logs with MSSQL is much better than any alternative ive found with PG, but tbf I haven't looked into it very far. When it comes up though it would be really nice to be able to restore to point in time easily with PG.
- I do occassionally come across missing functions in PG, but thats getting more and more rare.
- Cloud offerings - they exist for PG and are great for what they offer, but many extensions are not available or not fully configurable which is also sometimes hard to even determine.
All that said - if you aren't already invested in the MS ecosystem, PG would be my preference for sure. JSON/hstore/arrays alone make so many things possible even if you arent using those datatypes in your tables.
For basic querying I use SQLTabs, for DBA-type stuff I use PG Admin 3.
In PG triggers are row by row. In mssql it's one batch where you can access the inserted/deleted records.
You can use order by in a CTE in mssql, you just have to specify a TOP clause.
;with bar as (
select top 100 percent *
from foo
order by foo.name
)
select *
from barThat section on "Reliability" is pure comedy, the only time I had SQL Server "crash" was due to faulty hardware. And despite the best efforts of our previous data centre company (who we've since ditched) dropping the ball and losing power across the site multiple times over two years our MS SQL servers never lost any data, despite the rug being pulled whilst under some fairly heavy workloads. I should add that neither did any of the MySQL fleet, even the ones running replication.
One day when I get time I'll get around disembollocking this flawed article. I don't say that as a MS SQL "fanboy", but as a DBA with coming on for 20 years experience managing and programming SQL Server in banks, blue chips and ISP's (yeah I know, "appeal to authority"-fail, but who the hell is this anonymous author, and what are his credentials?).
Edit: sorry I should add I quite like PostgreSQL, and I'm hoping to roll it out as a service offering to our client base in the next few months, so no axe to grind from me with regards to its features and capabilities.
Postgre wins for people who have no money.
SQL Servers wins for people who have money AND are somewhat invested in the Microsoft ecosystem.
By the way the article is from 2014 and states that he's been doing that for a decade.
An article on the capabilities of postgre (or lack thereof) in 2004 and 2009, that'd be fun.
The last time this article came up the consensus was that the author was pretty biased towards Postgres and had little to no experience with actual MS SQL Server use. Also, the lack of author identity was frowned upon. Lastly, the conjecture and attitude towards Microsoft lacks some substance. Conclusion: The author is free to write whatever he likes, but take this resource with a pinch of salt. I use both Postgres and MS SQL Server professionally and whilst philosophically I prefer Postgres, for practical reasons I truly prefer MS SQL Server, if only because of its excellent development tools.
I've been doing databases professionally for 20+ years. I've used all of the big names apart from DB2, just never encountered it. Whether it's SQLite, PG, MariaDB, SQL Server, Sybase, Informix, Oracle, there's a right tool for the job.
Also a "data analyst" who never encounters a situation where parallel query will help is a person who works on very small datasets on a single disk or maybe a small RAID5 array.
https://news.ycombinator.com/item?id=9464505 (2 years ago, 135 comments, "dupe")
https://news.ycombinator.com/item?id=8615320 (2.3 years ago, 103 comments)
>You'd rather stick with a clumsy, awkward, unreliable system than spend the trivial amount of effort it takes to learn a slightly different dialect of a straightforward querying language? Well, just hope you never end up in a job interview with me.
I imagine anyone who easily dismisses MSSQL would be an easy interview. A good engineer will recognize the pros and cons of each database and make their decision based on their requirements. To dismiss MSSQL outright is pretty noobish, even for a lowly data analyst.
So, going through old docs, Postgres seems to have had stored procs using procedural languages since at least version 7.1, released in April 2001. It clearly has had them for quite some time, at any rate.
I've found it one of the best tutorials of anything on the web. It's challenging and you learn through example.
The Wayback Machine.
# Name | Popularity | Avg salary global
1. Mysql | 7.44% | $56,506
2. PostgreSQL | 4.32% | $61,505
3. MongoDB | 3.2% | $64,206
4. Sql Server | 2.71% | $65,959
5. Oracle | 2.09% | $52,312
6. Redis | 1.92% | $51,728
More stats and details here https://jobsquery.it/stats/databases/group