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.
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 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 7 years ago.
Improve this question
I am in the middle of designing a highly-scalable application which must store a lot of data. Just for example it will store lots about users and then things like a lot of their messages, comments etc. I have always used MySQL before but now I am minded to try something new like couchdb or similar which is not SQL.
Does anyone have any thoughts or guidance on this?
Here's a quote from a recent blog post from Dare Obasanjo.
SQL databases are like automatic
transmission and NoSQL databases are
like manual transmission. Once you
switch to NoSQL, you become
responsible for a lot of work that the
system takes care of automatically in
a relational database system. Similar
to what happens when you pick manual
over automatic transmission. Secondly,
NoSQL allows you to eke more
performance out of the system by
eliminating a lot of integrity checks
done by relational databases from the
database tier. Again, this is similar
to how you can get more performance
out of your car by driving a manual
transmission versus an automatic
transmission vehicle.
However the most notable similarity is
that just like most of us can’t really
take advantage of the benefits of a
manual transmission vehicle because
the majority of our driving is sitting
in traffic on the way to and from
work, there is a similar harsh reality
in that most sites aren’t at Google or
Facebook’s scale and thus have no need
for a Bigtable or Cassandra.
To which I can add only that switching from MySQL, where you have at least some experience, to CouchDB, where you have no experience, means you will have to deal with a whole new set of problems and learn different concepts and best practices. While by itself this is wonderful (I am playing at home with MongoDB and like it a lot), it will be a cost that you need to calculate when estimating the work for that project, and brings unknown risks while promising unknown benefits. It will be very hard to judge if you can do the project on time and with the quality you want/need to be successful, if it's based on a technology you don't know.
Now, if you have on the team an expert in the NoSQL field, then by all means take a good look at it. But without any expertise on the team, don't jump on NoSQL for a new commercial project.
Update: Just to throw some gasoline in the open fire you started, here are two interesting articles from people on the SQL camp. :-)
I Can't Wait for NoSQL to Die (original article is gone, here's a copy)
Fighting The NoSQL Mindset, Though This Isn't an anti-NoSQL Piece
Update: Well here is an interesting article about NoSQL
Making Sense of NoSQL
Seems like only real solutions today revolve around scaling out or sharding. All modern databases (NoSQLs as well as NewSQLs) support horizontal scaling right out of the box, at the database layer, without the need for the application to have sharding code or something.
Unfortunately enough, for the trusted good-old MySQL, sharding is not provided "out of the box". ScaleBase (disclaimer: I work there) is a maker of a complete scale-out solution an "automatic sharding machine" if you like. ScaleBae analyzes your data and SQL stream, splits the data across DB nodes, and aggregates in runtime – so you won’t have to!
And it's free download.
Don't get me wrong, NoSQLs are great, they're new, new is more choice and choice is always good!! But choosing NoSQL comes with a price, make sure you can pay it...
You can see here some more data about MySQL, NoSQL...: http://www.scalebase.com/extreme-scalability-with-mongodb-and-mysql-part-1-auto-sharding
Hope that helped.
One of the best options is to go for MongoDB(NOSql dB) that supports scalability.Stores large amounts of data nothing but bigdata in the form of documents unlike rows and tables in sql.This is fasters that follows sharding of the data.Uses replicasets to ensure data guarantee that maintains multiple servers having primary db server as the base. Language independent.
Flexible to use
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
What's the limitation?
Is there a specific volume of data each can handle regardless of disk space?
When to use what assuming licensing is not a problem?
This is a very nuanced question that really cannot be easily answered, as each situation can provide many pluses and minuses. Also, MySQL being owned by Oracle now and several branches off of the main functionality means that MySQL != MySQL anymore.
If you are looking for really really big data sets, then you will like have to break with the RDBMS sets and start to look at things like MapReduce and other large data set processing technologies.
I have personally worked with all three over the past decade or so from the application perspective. They all have their advantages, like MSSQL working will with the other Microsoft technologies like LINQ where as MySQL having a large open community support and Oracle being the workhorse of the commercial sector with lots of ability to embed application logic right into the database.
Again, it really depends on the application, the situation, the skills of the people who will maintain it after it is developed, commercial considerations, hardware and platform considerations, etc etc etc.
It depends what you are trying to do and obviously it has to do with cost.
MySQL and Postgres are very widely used by a huge number of startups because its open source and there is a lot of support out there for people using it
MSSQL is good if you are using MS programming languages because of the ease to connect and use.
I have never used oracle but know people use it a lot for data warehouseing so can't have that much of a bad name
All of these will suffer from similar issues when scaling because they are RDBMS databases. They do also have decent ways to get round it and with a decent ORM used in your code then it shouldn't matter what you use.
Pick the one that all the developers are comfortable with
I'd say if you want to compare apples to apples, then it is MySQL vs SQL Express, vs Oracle Express.
Or if you have $, then it is the MySQL support license, MS-SQL Standard, vs whatever Oracle's cheapest offering is.
In my experience, once you choose a language, e.g. Php goes best with MySQL, then you've chosen your DB. Java goes well with Oracle. C# goes well with MSSQL.
Similarly, if you choose your OS, then unix flavors run MySQL or Oracle, but MSSQL is windows only. MySQL and Oracle work on both unix and windows of course.
If you need to buy many machines, then not having to pay OS licenses for the server helps in scaling.
As to skaffman's point you may want to have a look at postgres if mysql isn't scaling for you. It is a more mature and robust than mysql and is opensource. The time to make the switch is highly dependent on you application environment, however, if you need clustering and replication to work properly 100% of the time then postgres will not let you down (as mysql has for me in the past)
It would help narrow things a great deal if you'd provide details like whether or not you intend to distribute the database along with your software; your system will be hosted; how much data; etc.
Don't assume anything with regard to licensing. Get a lawyer, maybe even one who specializes in open source law.
"...regardless of disk space..." - capacity always depends on this. Where do you think the data goes? Better to think about things like sharding your data, RAID, clustering, replication, etc.
I would worry about any system whose developer had to come to a forum like this to ask that kind of question. You should have people on staff with sufficient skill and knowledge to have a strong opinion on this sort of thing.
Perhaps one variable which people overlook in these cases is the availability of expert support. Okay, so currently there's an oversupply of people who can help you with db issues, efficiency issues, disaster recovery etc. However this may not be always the case in the future, and it's the applications you use it for that may be the defining issue. Are there people in your organization who have experience in one or more of the relevant databases? (as it happens I believe that someone's who's become proficient in say Oracle, can become fairly competent in Sql*Server or Mysql in a fairly short space of time) You state it's going to be used for your financial systems - perhaps you really need input from a consultant who's worked on implementing and/or supporting financial systems - for example I understand that Sybase is popular in City type firms. Or perhaps there's an off-the-shelf package that utilises a preferred database? Try and define exactly what your system(s) needs to do first.
Is the application buy or build ?
If Buy, does it support all three and
talk to the app vendor about the
differences ?
If Build, then is it an in-house
build or contract out. If contracting
out, put out your requirements and
let the suppliers put their
arguments.
If in house build, then first look at
why you are not contracting out.
Normally it is because you already
have an in house capability, so look
at that expertise.
You want some sizing information first.
Are you talking data volumes in megabytes, gigabytes or terabytes ?
What are your uptime requirements, backup (recovery time / recovery point) ?
How much concurrent activity ? Is that peak ?
Generally any database system is fine for data storage and retrieval. High-end analysis, load balancing, replication, management, backup/recovery, auditability, security are all areas you may need to consider.
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.