Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
IS there much difference between MySQL and PostgreSQL for a beginner like me, using basic select statements and the like, or are the main differences with using more advanced queries?
The reason why I usually suggest PostgreSQL before MySQL is because MySQL is far from the standards (SQL-wise). It does not support the use of window functions (8.4 version), common table expressions (8.4), CHECK constraints, EXCEPT/MINUS operator, even FULL OUTER JOINs... Even though you may have never heard of these words, you'll have to use those concepts at some point.
I strongly suggest you to start with PostgreSQL, then you can learn what "real" SQL is. Then, you can decide if MySQL is sufficient or not.
P.S. I started with MySQL and I regretted it. I now use PostgreSQL and I love it.
There have already been a lot of great points in favor of PostgreSQL, but I am going to add 1 more:
PostgreSQL has the best documentation of any database product I have worked with.
This is why the documentation stands out:
It actually teaches you the basics of SQL
It is easy to understand
It has good examples
It is very well organized
It isn't just a feature list with tech notes
It is all around, well written
Other vendors should be ashamed of what they try and a pass off as documentation.
While you're just starting out I think you'll appreciate PostgreSQL's pgadminIII GUI tool more than you would those that I've tried for MySQL. This may just be my preference, however.
When you get past the basics you will definitely want to take advantage of PostgreSQL's support of window functions starting in version 8.4
I'd actually recommend PostgreSQL over MySQL for the window functions alone. Note that there are ways to emulate window functions in MySQL.
You often hear PostgreSQL enthusiasts argue that it's a "real" RDBMS, while MySQL is not. This kind of snobbery is dangerous for newcomers, because it comes after years of specific experiences that rub a certain way against a certain personality type. If you want to approach it in terms of what knowledge would benefit a beginner the most - you're far more likely to find people using MySQL out in the wild than PostgreSQL. Big sites built around open source software choose MySQL over PostgreSQL by a wide margin.
Personally, I like MySQL because it fits my development style - it just gets stuff done. I don't use foreign keys. I definitely don't use stored procedures. But what MySQL does, it does well and it does fast and it does it while giving me a happy "okay, that makes sense" feeling that I don't get with PostgreSQL (I've used both extensively). There's good community support for MySQL and excellent documentation. And if you need to do replication (and who doesn't?) MySQL is the clear winner, no questions asked.
There are some things that MySQL lets you do that could possibly lead to bad habits if you switch to less-forgiving databases. But that's the thing - there's all this talk of how you need to be prepared to jump from RDBMS X to RDBMS Y at a moment's notice. In my experience, this happens rarely, and when it does there are always quirky differences from one database to the next. MySQL is different from PostgreSQL, which is different from Oracle, which is different from SQL Server, which is different from sqlite, etc, etc. I've used all the dbs I listed above, but the one I keep coming back to, the one that gets things done most easily and flexibly for me, is MySQL.
DBAs love to put down MySQL the same way programming language aficionados love to bash PHP - and yet they survive and thrive. There are reasons for this - they just work, they just get stuff done. But at the end of the day you should play around with all of it and make up your own mind.
I would recommend PostgreSQL for a beginner as it has far fewer surprises than MySQL.
Here are some of the things that people run into with MySQL:
http://blog.amber.org/2005/09/27/least-common-denominator/
http://arstechnica.com/civis/viewtopic.php?f=20&t=92525
http://exortech.com/blog/2009/11/30/weekly-release-53-environment-bug-bites/
Meanwhile, PostgreSQL does exactly what you expect it to do in most situations, and usually has a very good reason when it does something unexpected.
PostgreSQL supports more advanced queries, it performs better on complicated queries, but is harder to manage.
MySQL is fast, easy to manage, but you can run into it's limitations on advanced queries, stored procedures and the like.
They are sufficiently similar that I'd recommend starting with MySQL but learning PostgreSQL as well.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
IS there much difference between MySQL and PostgreSQL for a beginner like me, using basic select statements and the like, or are the main differences with using more advanced queries?
The reason why I usually suggest PostgreSQL before MySQL is because MySQL is far from the standards (SQL-wise). It does not support the use of window functions (8.4 version), common table expressions (8.4), CHECK constraints, EXCEPT/MINUS operator, even FULL OUTER JOINs... Even though you may have never heard of these words, you'll have to use those concepts at some point.
I strongly suggest you to start with PostgreSQL, then you can learn what "real" SQL is. Then, you can decide if MySQL is sufficient or not.
P.S. I started with MySQL and I regretted it. I now use PostgreSQL and I love it.
There have already been a lot of great points in favor of PostgreSQL, but I am going to add 1 more:
PostgreSQL has the best documentation of any database product I have worked with.
This is why the documentation stands out:
It actually teaches you the basics of SQL
It is easy to understand
It has good examples
It is very well organized
It isn't just a feature list with tech notes
It is all around, well written
Other vendors should be ashamed of what they try and a pass off as documentation.
While you're just starting out I think you'll appreciate PostgreSQL's pgadminIII GUI tool more than you would those that I've tried for MySQL. This may just be my preference, however.
When you get past the basics you will definitely want to take advantage of PostgreSQL's support of window functions starting in version 8.4
I'd actually recommend PostgreSQL over MySQL for the window functions alone. Note that there are ways to emulate window functions in MySQL.
You often hear PostgreSQL enthusiasts argue that it's a "real" RDBMS, while MySQL is not. This kind of snobbery is dangerous for newcomers, because it comes after years of specific experiences that rub a certain way against a certain personality type. If you want to approach it in terms of what knowledge would benefit a beginner the most - you're far more likely to find people using MySQL out in the wild than PostgreSQL. Big sites built around open source software choose MySQL over PostgreSQL by a wide margin.
Personally, I like MySQL because it fits my development style - it just gets stuff done. I don't use foreign keys. I definitely don't use stored procedures. But what MySQL does, it does well and it does fast and it does it while giving me a happy "okay, that makes sense" feeling that I don't get with PostgreSQL (I've used both extensively). There's good community support for MySQL and excellent documentation. And if you need to do replication (and who doesn't?) MySQL is the clear winner, no questions asked.
There are some things that MySQL lets you do that could possibly lead to bad habits if you switch to less-forgiving databases. But that's the thing - there's all this talk of how you need to be prepared to jump from RDBMS X to RDBMS Y at a moment's notice. In my experience, this happens rarely, and when it does there are always quirky differences from one database to the next. MySQL is different from PostgreSQL, which is different from Oracle, which is different from SQL Server, which is different from sqlite, etc, etc. I've used all the dbs I listed above, but the one I keep coming back to, the one that gets things done most easily and flexibly for me, is MySQL.
DBAs love to put down MySQL the same way programming language aficionados love to bash PHP - and yet they survive and thrive. There are reasons for this - they just work, they just get stuff done. But at the end of the day you should play around with all of it and make up your own mind.
I would recommend PostgreSQL for a beginner as it has far fewer surprises than MySQL.
Here are some of the things that people run into with MySQL:
http://blog.amber.org/2005/09/27/least-common-denominator/
http://arstechnica.com/civis/viewtopic.php?f=20&t=92525
http://exortech.com/blog/2009/11/30/weekly-release-53-environment-bug-bites/
Meanwhile, PostgreSQL does exactly what you expect it to do in most situations, and usually has a very good reason when it does something unexpected.
PostgreSQL supports more advanced queries, it performs better on complicated queries, but is harder to manage.
MySQL is fast, easy to manage, but you can run into it's limitations on advanced queries, stored procedures and the like.
They are sufficiently similar that I'd recommend starting with MySQL but learning PostgreSQL as well.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Now that MySQL is in Oracle's hands, do you think it's a good idea to switch to using PostgreSQL for new applications instead? (Also what do you think about converting existing applications?)
I've used both DB systems before and while PostgreSQL is great for it's licensing terms and standards compliance, MySQL is definitely easier to get up and running quickly. (I make this as a personal observation, I know you might disagree...)
Edit:
I should clarify... I don't want this to be a MySQL/PostgreSQL is better than PostgreSQL/MySQL debate. I like both DB systems and am happy using both (and really for the complexity of most of the applications I'm working on, it's much of a muchness). I'm just in a position where I'm trying to look forward and consider the stability of my technology base before committing myself to a particular course. If you have gone through a similar process and have some kind of migration plan in mind I would like to hear from you regarding what that is and why you decided on it.
Installing is a one-time-job ... kindof. Depends ofcourse. but PostgreSQL isn't much harder to install than MySQL, if harder at all. It's the day-to-day cost of ownership that matters. As a developer I prefer PostgreSQL over MySQL, as the latter behaves different from version to version (they're still playing catchup to the sql standard and probably always will). Also MySQL is a pain to administer sometime. What does it matter if it takes ten minutes more to install if you must wait for hours when adding a column to a table or other trivial tasks. Finally I think the mysql-environment was too turbulent even before the Oracle takeover, with Oracle already owning innoDB, MariaDB. I think it is a general mess. So yes, I'd migrate, but for other reasons.
If you actually prefer MySQL over PostgreSQL I'd lay out a migration plan just to be ready if need arises, as a kind of lazy proactiveness ...
Look at it this way: regardless of what Oracle says, the fact remains that they could decide to do Something Bad with MySQL at any time. Maybe they will, and maybe they won't, but why take the risk (for new projects, at least) when you can just use PostgreSQL?
Given the choice, I'd just as soon go with Postgres myself. It seems to be a very stable project upon which to base my own work. Long history, under active development, good documentation, etc.
Since you've indicated that you're happy working with either one, I say go with Postgres for new projects and don't worry about converting existing projects unless and until Oracle does something with MySQL that gives you cause for concern.
I am no fan of Oracle, but the company has come forward with a 10 point commitment to existing MySQL customers.
So at least as of now, I don't see any cause for worry. Any database migration will require some effort and cost in terms of time and money. So if I were you, I'd hold on for a while before doing anything drastic as a database migration.
Even if MySQL does go south, there's MariaDB, which was started by the founder of MySQL. It's a drop in replacement and has some quite exciting new features.
http://askmonty.org/wiki/index.php/MariaDB
I've been giving a go on my development environment and I've been liking it so far.
See the article:
Save MySQL by letting Oracle keep it GPL
This answers your question amongst other things.
Good lord.
O.k. so let's just get it in the open. I am not a MySQL fan. I think its broken. However I am biased (http://www.commandprompt.com/). That said here are the benefits of PostgreSQL.
PostgreSQL scales farther than MySQL. MySQL does really well if you have a limited number of CPUs. If you get above 4, PostgreSQL will just go farther, longer.
PostgreSQL's license allows it to never be bought. You don't have to worry about a single entity taking it over. At present there are at least a dozen actively supporting companies including, Red Hat, PgExperts, Command Prompt, OmniTI, EnterpriseDB, Fujitsu and Oracle (yep).
PostgreSQL's feature set is remarkable. Just look at it.
However, and this is the most important. Do what your business requires. MySQL is a decent database when used for its purpose.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Am not sure if this question makes sense. But I know all the basic CRUD commands of mysql. Probably a bit more here and there (foreign keys etc). But there are so many books written on mysql/dbms. I can write decent queries and get all my results as I want them. Maybe they aren't the most efficient but it worksforme. Thats because my apps arent facebook as yet that I have to worry about optimization. Or do I?
Am I missing the point here? What else should I know?
Thank you very much.
Premature optimization is the root of all evil. Focus on designing proper and logical database structures and indexing them correctly, that will take you far. Modifying a badly written query is always easier than modifying a badly designed database structure.
In my opinion, use the queries you have and optimize them when there is a need for optimization. What comes to the queries, rather focus on making them secure (see sql injection).
What else should I know?
Greater understanding of relational theory, so you write better SQL. I'm currently enjoying "SQL and Relational Theory," a new book by C. J. Date, the world's leading expert on the relational model.
Implementing and monitoring security - SQL injection certainly, but other issues covered by OWASP, SANS.org, or books like "19 Deadly Sins of Software Security." This is a broad topic not specific to SQL, but I think it's every software developer's duty to learn this stuff.
Performance measurement and monitoring - how will you know when you reach the point where you do need to learn optimization techniques?
I18N, L10N, character sets.
Database maintenance and recovery - backups, repair.
Replication, clustering, and proxying.
Deployment and upgrade techniques - how to apply changes to a running application or site without interrupting service.
Writing more-or-less portable SQL that works with multiple RDBMS brands. At least understand what needs to be rewritten if you need to support another brand.
How and when to employ Object-Relational Mapping frameworks.
How and when to employ non-relational databases. SQL is the best general-purpose data management paradigm, but there are other technologies more specialized to specific tasks.
Advanced MySQL is probably not just about writing queries for CRUD operations. Sometimes you need to do optimizations or various maintenance procedures that do require an intimate knowledge of the DBMS you are working with. You might not be worried about the performance of your queries and the robustness and efficiency of your database design if you deal with small to medium sized applications, but for a highly scalable application all these are factors that you have to take into account.
It's good to know CRUD syntax well. I would recommend that you go beyond that to understand relational design, primary and candidate keys, indexing, etc. These are topics that are meaningful for all relational databases, not just MySQL.
Databases are much more than just "Places to put stuff". Once you realize that, you will start using them to their full potential.
You should worry about optimization anyway imho. Sure if right now you have only 10 people who are using your application it's not the issue, but in the future if the user base grows it can really be a "pain in the ass" to rewrite database structure, especialy if in your code you are using the raw queries without database abstraction.
If you know enough to to do what needs to be done, then you know enough for now. However, Introduction to Database Systems by C.J. Date is an outstanding discussion of relational databases written by a pioneer in the field (as well as other types of database systems).
Generally, there are tons of features of mysql and other RDBMS systems that people aren't aware of. This is fine since you can get by well with a subset of features, but to deal with difficult problems or to be a good DBA there's a huge amount of stuff to learn. When people talk about Advanced X on databases, these are the types of things that are meant.
To answer your question, it's never a bad idea to find out what other features and tools are out there. You may find much better ways of solving your own problems and develop a better set of skills for solving other people's problems. I also fully agree with the other answers suggesting that you improve your knowledge on higher level topics, knowing how to make good db designs is extremely important.
Oh, now I get it (the question). I thought you meant "What is the point of combining 'Advanced' and 'MySQL'?". :-)
If you MUST use MySQL for your job, then yes, you had better gradually get a deeper understanding of it, especially what the shortcomings and gotchas are, and how other people at work may make assumptions about things that are not really going to work out.
Now, my "troll": if this is just you, use something a bit more robust. I'm no MicroSoft fan, but they do make the startup costs for using SQL Server pretty low, assuming you are working on Windows. Better yet, if you are working on a *nix server, you might try PostgreSQL. They have been pretty serious about correctly implementing quaint little things like ROLLBACK, transaction isolation, foreign key referential integrity, views, functions (aka stored procedures) for quite a few years. MySQL has improved over the years, but is still (IMHO) somewhat immature. My impression of it back around 2000 was "the reliability of xBASE with the ease of the SQL interface". (I'm not a big fan of the SQL language itself -- maybe I'm just too old to really warm up to it as the "the only possible way to do it")
I avoid MySQL like a bad flu bug, but I can add some insight here.
One area that would be covered in the "advanced" portion of MySQL is customization.
There is alot involved with SQL in general that MySQL doesn't do out of the box, or can be customized. Our company uses full stored procedure implementation and geospatial queries as two examples.
Advanced would involved good customization skills, and experience adding and working with customizations or add-ins. Anything to make MySQL be more enterprise like.
I and two others are working on a project at the university.
In the project we are making a prototype of a MMORPG.
We have decided to use PostgreSQL as our database. The other databases we considered were MS SQL-server and MySQL.
Does somebody have a good reference which will justify our choice? (preferably written during the last year)
Someone recently recommended me wikivs.com: MySQL vs. PostgreSQL - it is a quite detailed comparison of those two, and might be of help to you.
the most mentioned difference between MySQL and PostgreSQL is about your reading/writing ratios. If you read a lot more than you write, MySQL is usually faster; but if you do a lot of heavy updates to a table, as often as other threads have to read, then the default locking in MySQL is not the best, and PostgreSQL can be a better choice, performance-wise.
IOW, PostgreSQL scales better regarding to DB writes.
that's why it's usually said that MySQL is best for webapps, while PostgreSQL is more 'enterprisey'.
Of course, the picture is not so simple:
InnoDB tables on MySQL have a very different performance behaviour
At the load levels where PostgreSQL's better locks overtake MySQL's, other parts of your platform could be the bottlenecks.
PostgreSQL does comply better with standards, so it can be easier to replace later.
in the end, the choice has so many variables that no matter which way you go, you'll find some important issue that makes it the right choice.
Go with something that someone in your team has actual experience of using in production. All databases have issues which frequent users are aware of.
I cannot stress enough that someone in the team needs PRODUCTION experience of using it. Not using it for their homework, or to keep their list of CDs in.
All of these databases have their advantages and disadvantages. Which is better is dependent on:
Your teams experience
Your exact requirements
Your current environemnt e.g. whats your app written in and going to be hosted on?
SQL servers main problem is the cost unless you use express edition which has performance limitations however its very easy to use and has a number of good tools.
There is a comparison of the different sql versions at:
http://www.microsoft.com/sql/prodinfo/features/compare-features.mspx
You could then compare these with MySQL and PostGre.
If the purpose of this comparison is a theoretical one for your essay then you can reference web pages such as the microsoft link and compare performance, cost etc.
Postgresql has a page of case studies that you can quote and link to.
Really, any of the above would have worked for you. I personally like PostgreSQL. One solid advantage it has over MSSQL (even assuming you can get it for "free") is that PostgreSQL is non-proprietary. If you're going to introduce a dependency into your project (and re-inventing an RDBMS would be crazy), you don't want it to be a black box.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am working on a web application using Python (Django) and would like to know whether MySQL or PostgreSQL would be more suitable when deploying for production.
In one podcast Joel said that he had some problems with MySQL and the data wasn't consistent.
I would like to know whether someone had any such problems. Also when it comes to performance which can be easily tweaked?
A note to future readers: The text below was last edited in August 2008. That's nearly 11 years ago as of this edit. Software can change rapidly from version to version, so before you go choosing a DBMS based on the advice below, do some research to see if it's still accurate.
Check for newer answers below.
Better?
MySQL is much more commonly provided by web hosts.
PostgreSQL is a much more mature product.
There's this discussion addressing your "better" question
Apparently, according to this web page, MySQL is fast when concurrent access levels are low, and when there are many more reads than writes. On the other hand, it exhibits low scalability with increasing loads and write/read ratios. PostgreSQL is relatively slow at low concurrency levels, but scales well with increasing load levels, while providing enough isolation between concurrent accesses to avoid slowdowns at high write/read ratios. It goes on to link to a number of performance comparisons, because these things are very... sensitive to conditions.
So if your decision factor is, "which is faster?" Then the answer is "it depends. If it really matters, test your application against both." And if you really, really care, you get in two DBAs (one who specializes in each database) and get them to tune the crap out of the databases, and then choose. It's astonishing how expensive good DBAs are; and they are worth every cent.
When it matters.
Which it probably doesn't, so just pick whichever database you like the sound of and go with it; better performance can be bought with more RAM and CPU, and more appropriate database design, and clever stored procedure tricks and so on - and all of that is cheaper and easier for random-website-X than agonizing over which to pick, MySQL or PostgreSQL, and specialist tuning from expensive DBAs.
Joel also said in that podcast that comment would come back to bite him because people would be saying that MySQL was a piece of crap - Joel couldn't get a count of rows back. The plural of anecdote is not data. He said:
MySQL is the only database I've ever programmed against in my career that has had data integrity problems, where you do queries and you get nonsense answers back, that are incorrect.
and he also said:
It's just an anecdote. And that's one of the things that frustrates me, actually, about blogging or just the Internet in general. [...] There's just a weird tendency to make anecdotes into truths and I actually as a blogger I'm starting to feel a little bit guilty about this
Just chiming in many months later.
The geographical capabilities of the two databases are very, very different. PostgreSQL has the exceptional PostGIS extension. MySQL's geographical functionality is practically zero in comparison.
If your web service has a location component, choose PostgreSQL.
I haven't used Django, but I have used both MySQL and PostgreSQL. If you'll be using your database only as a backend for Django, it doesn't matter much, because it will abstract away most of the differences. PostgreSQL is a little more scalable because it doesn't hit the brick wall as fast as MySQL as data-size/client-count increase.
The real difference comes in if you are doing a new system. Then I'd recommend PostgreSQL hands down, because it has a lot more features which make your DB layer much more customizable, so that you can fine-tune it to any requirements you might have.
Although it's a bit out of date, it would be worth reading the MySQL Gotchas page. Many of the items listed there are still true, to the best of my knowledge.
I use PostgreSQL.
I use both extensively. My choice for a particular project boils down to:
Licensing - Are you going to distribute your app (IANAL)
Existing Infrastructure and Knowledge Base
Any special sauce you have to have.
By special sauce I mean things like:
Easy/cheap replication = MySQL
Huge dataset problems with small results = PostgreSQL. Use the language extensions, and have very efficient data operations. (PL/Python, PL/TCL, PL/Perl, etc)
Interface with R Statistical Libraries = PostgreSQL PL/R available in debian/ubuntu
Well, I don't think you should be using a different database brand in anything past development (build, staging, prod) as that will come back to bite you.
From how I understand it PostgreSQL is a more 'correct' database implementation while mySQl is less correct (less compliant) but faster.
So if you are pretty much writing a CRUD application mySQL is the way to go. If you require certain features out of your database (if you're not sure then you don't) then you may want to look into postgreSQL.
If you are writing an application which may get distributed quite a bit on different servers, MySQL carries a lot of weight over PostgreSQL because of the portability. PostgreSQL is difficult to find on less than satisfactory web hosts, albeit there are a few. In most regards, PostgreSQL is slower than MySQL, especially when it comes to fine tuning in the end. All in all, I'd say to give PostgreSQL a shot for a short amount of time, that way you aren't completely avoiding it, and then make a judgement.
Thank you. I've used Django with MySQL and it's fine. Choose your database on the features you need. Hard to compare MySQL and Postgres. Better to compare Postgress to SQl Server.
#WolfmanDragon
PostgreSQL has (tiny) support for objects, but it is, by nature, a relational database. From its about page:
PostgreSQL is a powerful, open source relational database system.
MySQL is a relational database management system while PostgreSQL is an object-relational database management system. PostgreSQL is suited well for C++ or Java developers, as it gives us more control over how queries are written. ORDBMS also gives us Objects and User Defined Types. The SQL queries themselves are much closer to the ISO standards than MySQL.
Do you need an ORDBMS or a RDBMS? That will better answer your question.