MySQL vs. PostgreSQL vs. Microsoft SQL Server



Hacker News, Reddit, Stack Overflow Stats

  • 1.11K
  • 8.54K
  • 551K
  • 8.36K
  • 8.43K
  • 95.9K
  • 22K
  • 62.8K
  • 0

GitHub Stats

No public GitHub repository stats available

Description

What is MySQL?

The MySQL software delivers a very fast, multi-threaded, multi-user, and robust SQL (Structured Query Language) database server. MySQL Server is intended for mission-critical, heavy-load production systems as well as for embedding into mass-deployed software.

What is PostgreSQL?

PostgreSQL is an advanced object-relational database management system that supports an extended subset of the SQL standard, including transactions, foreign keys, subqueries, triggers, user-defined types and functions.

What is Microsoft SQL Server?

Microsoft® SQL Server is a database management and analysis system for e-commerce, line-of-business, and data warehousing solutions.

Want advice about which of these to choose?Ask the StackShare community!

Pros

Why do developers choose MySQL?
Why do you like MySQL?

Why do developers choose PostgreSQL?
Why do you like PostgreSQL?

Why do developers choose Microsoft SQL Server?
Why do you like Microsoft SQL Server?

Cons

What are the cons of using MySQL?
Downsides of MySQL?

What are the cons of using PostgreSQL?
No Cons submitted yet for PostgreSQL
Downsides of PostgreSQL?

What are the cons of using Microsoft SQL Server?
No Cons submitted yet for Microsoft SQL Server
Downsides of Microsoft SQL Server?

Companies

What companies use MySQL?
3651 companies on StackShare use MySQL
What companies use PostgreSQL?
3169 companies on StackShare use PostgreSQL
What companies use Microsoft SQL Server?
598 companies on StackShare use Microsoft SQL Server

Integrations

What tools integrate with MySQL?
79 tools on StackShare integrate with MySQL
What tools integrate with PostgreSQL?
90 tools on StackShare integrate with PostgreSQL
What tools integrate with Microsoft SQL Server?
26 tools on StackShare integrate with Microsoft SQL Server

What are some alternatives to MySQL, PostgreSQL, and Microsoft SQL Server?

  • MongoDB - The database for giant ideas
  • MariaDB - An enhanced, drop-in replacement for MySQL
  • SQLite - A software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine
  • Memcached - High-performance, distributed memory object caching system

See all alternatives to MySQL

Latest News

JSON specific window functions in MySQL 8.0
Hybrid OLTP/Analytics Database Workloads in Galera C...
Monitoring ProxySQL with PMM in Docker
9.6.12
10.7
9.5.16
Microsoft SQL Server cookbook release – 5.4.0
Related Stack Decisions
Gregory Koberger
Gregory Koberger
Founder · | 8 upvotes · 11951 views
atReadMe.io
Compose
MongoLab
MongoDB Atlas
PostgreSQL
MySQL
MongoDB

We went with MongoDB , almost by mistake. I had never used it before, but I knew I wanted the *EAN part of the MEAN stack, so why not go all in. I come from a background of SQL (first MySQL , then PostgreSQL ), so I definitely abused Mongo at first... by trying to turn it into something more relational than it should be. But hey, data is supposed to be relational, so there wasn't really any way to get around that.

There's a lot I love about MongoDB, and a lot I hate. I still don't know if we made the right decision. We've been able to build much quicker, but we also have had some growing pains. We host our databases on MongoDB Atlas , and I can't say enough good things about it. We had tried MongoLab and Compose before it, and with MongoDB Atlas I finally feel like things are in a good place. I don't know if I'd use it for a one-off small project, but for a large product Atlas has given us a ton more control, stability and trust.

See more
Tim Abbott
Tim Abbott
Founder at Zulip · | 8 upvotes · 11027 views
atZulip
Elasticsearch
MySQL
PostgreSQL

We've been using PostgreSQL since the very early days of Zulip, but we actually didn't use it from the beginning. Zulip started out as a MySQL project back in 2012, because we'd heard it was a good choice for a startup with a wide community. However, we found that even though we were using the Django ORM for most of our database access, we spent a lot of time fighting with MySQL. Issues ranged from bad collation defaults, to bad query plans which required a lot of manual query tweaks.

We ended up getting so frustrated that we tried out PostgresQL, and the results were fantastic. We didn't have to do any real customization (just some tuning settings for how big a server we had), and all of our most important queries were faster out of the box. As a result, we were able to delete a bunch of custom queries escaping the ORM that we'd written to make the MySQL query planner happy (because postgres just did the right thing automatically).

And then after that, we've just gotten a ton of value out of postgres. We use its excellent built-in full-text search, which has helped us avoid needing to bring in a tool like Elasticsearch, and we've really enjoyed features like its partial indexes, which saved us a lot of work adding unnecessary extra tables to get good performance for things like our "unread messages" and "starred messages" indexes.

I can't recommend it highly enough.

See more
Conor Myhrvold
Conor Myhrvold
Tech Brand Mgr, Office of CTO at Uber · | 3 upvotes · 18710 views
atUber Technologies
Python
MySQL
PostgreSQL

Our most popular (& controversial!) article to date on the Uber Engineering blog in 3+ yrs. Why we moved from PostgreSQL to MySQL. In essence, it was due to a variety of limitations of Postgres at the time. Fun fact -- earlier in Uber's history we'd actually moved from MySQL to Postgres before switching back for good, & though we published the article in Summer 2016 we haven't looked back since:

The early architecture of Uber consisted of a monolithic backend application written in Python that used Postgres for data persistence. Since that time, the architecture of Uber has changed significantly, to a model of microservices and new data platforms. Specifically, in many of the cases where we previously used Postgres, we now use Schemaless, a novel database sharding layer built on top of MySQL (https://eng.uber.com/schemaless-part-one/). In this article, we’ll explore some of the drawbacks we found with Postgres and explain the decision to build Schemaless and other backend services on top of MySQL:

https://eng.uber.com/mysql-migration/

See more


Interest Over Time