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 guess this has been brought up many times, but I'm bringing it up again!!!
Anyway... In Ruby on Rails Sqlite3 is already setup and no extra picking and slicing is needed, but...
after numerous readings here and other places, some say it's not scalable while others say it can actually be quite good at that. Some say MySQL is much better for bigger projects, while others think, just go with PostgreSQL.
I'm interested in hearing your opinion on this. In two scenarios. One where you are starting a little website for news publishing website like CNN news, and the other scenario where you're creating a website similar to Twitter?
Highly depends on your application.
Generally spoken, any write operation into a SQLite database is slow. Even a plain :update_attribute or :create may take up to 0.5 seconds. But if your App doesn't write much (killer against SQLite: write to DB on every request!), SQlite is a solid choice for most web apps out there. It is proven to handle small to medium amounts of traffic. Also, it is a very good choice during development, since it needs zero configuration. It performs also very well in your test suite with the in-memory mode (except you have thousands of migrations, since it rebuilds from scratch every time). Also, it is mostly seamless to switch from SQLite to, eg MySQL if its performance isn't enough any longer.
MySQL is currently a rock-solid choice. Future will tell what happens to MySQL under Oracle.
PostgreSQL is the fastest one as far as I know, but I haven't used it in production yet. Maybe others can tell more.
I'd vote for Postgres, it's consistently getting better, especially performance wise if that's a concern. Taking you up on the CNN and Twitter examples, start out with as solid footing as you can. You'll be glad later on down the road.
For websites, SQLite3 will suffice and scale fine for anything up to higher middle class traffic scenarios. So, unless you start getting hit by millions of requests per hour, there's no need to worry about SQLite3's performance or scalability.
That said, SQLite3 doesn't support all those typical features that a dedicated SQL server would. Access control is limited to whatever file permissions you can set for UNIX accounts on the machine with your database file, there's no daemon to speak of and the set of built-in functions is rather small. Also, there's no stored procedures of any kind, although you could emulate those with views and triggers.
If you're worried about any of those points, you should go with PostgreSQL. MySQL has (indirectly) been bought by Oracle, and considering they also had their own database before acquiring MySQL, I wouldn't put it past them to just drop it somewhere along the line. I've also had a far smoother experience maintaining PostgreSQL in the past and - anecdotally - it always felt a bit snappier and more reliable.
DISCLAIMER:
My opinion is completely bias as I have used mysql since it first came out.
Your question brings in another argument about how your development environment should be setup. A number of individuals will argue that you should be using the same dbms in development as you do in testing/production. This is totally dependent upon what you're doing in the first place. Sqlite will work fine, on development, in most cases.
I've personally been involved with more sites using MySql and MsSql than Postgres.
I was involved in a project that scrubbed the National Do-Not-Call list against client numbers. We stored that data locally. Some area codes easily have over 5 million records. The app was initially written in .Net using MsSql. It was "not-so-fast". I changed it to use PHP and MySql (Sad says before I found out about Ruby). It would insert/digest 5 million rows in(about) 3 seconds. Which was infinitely faster than processing it through MsSql. We also stored call log data in tables that would grow to 20 million records in less than a day. MySql handled everything we threw at it like a champ. The processing naturally took a hit when we setup replication but it was such a small one that we ignored it.
It really comes down to your project and what solution fits the need of the project.
Related
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 understand that this is very broad so let me give you the setting and be specific about my focus points.
Setting:
I am working with an existing PHP application using MYSQL. Tables almost all use the MYISAM engine and contain millions of rows for the most part. One of the largest tables uses an EAV design which is necessary but impacts on performance. The application was written to best leverage MYSQL cache. It requests a fair amount of requests per page load (partialy because of this) and is complex enough to have to go through most tables of the whole DB on each page load.
Pros:
it's free
MYISAM tables support full text indexes which are important to the application
Cons:
With the way things are set up, MYSQL is limited to one CPU for the whole of the application. If one very demanding query is run (or server is under a lot of load) it will queue all others making the site unresponsive
MYSQL caching and lack of "WITH" or "INTERSECT" means we have to break our queries down to better use cache. Thus multiplying the number of queries made. For instance, using subqueries over multiple tables with millions of rows (even with decent indexing) turns out to be a big issue with the current/upcomming load and the constraint layed out in the point above (CPU usage)
Feeling the need to scale up in the upcomming year, but not necessarily ready to pay for licensing right away, I've been thinking about rewriting the application and switching DBs.
The three options being considered are to either continue using mysql but with the INNODB engine, this way we can leverage more CPU power. Adapt to Oracle XE and get a license when we need to scale upwards of 4Gb database, 1Gb RAM or the 1 CPU limit (all of which we haven't hit yet). Or adapt to PostgreSQL
So the questions are :
How would losing full text indexing impact performance in the three cases (does oracle or postgreSQL have an equivalent?)
How do oracle and postgreSQL leverage cache on subqueries, WITH, and UNION/INTERSECT statements
How do Oracle and PostgreSQL leverage multicore/cpu power (if/when we get an oracle license)
I think that's already a lot to answer so I'll stop here. I don't mind simple/incomplete answers if there are links to compliment.
If you need any more information just let me know
Thanks in advance guys, the help is appreciated.
PostgreSQL supports full text search and indexes. Details here.
And it can use any number of CPU cores. It creates separate process for every session + some additional support processes. Details here.
PostgreSQL doesn't have built in query caching, but there are lots of open source utilities for this 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 10 years ago.
Dear all Stackoverflowers,
I just started to learn programming and now I'm putting this question online based on a quote: no question is silly
My work needs to develop a order system based on web, which wants a database system. Since using Excel for years as a general office user, I naturally turn this to Access. However, most people say Access is very limited comparing to MySQL or MSSQL, or any other more professional database system.
But after developing some functions for my company's order system, I really find Access can fulfill my request. And I also tried MSSQL to develop, which I found it not quite convenient to use.
I have searched in stackoverflow and find no general answer about my doubt. Now I am sincerely hoping some experienced and professional developers could clear my doubts.
Now I'm listing some Access advantages, which I don't think other database system have. I hope you could help me also find these advantages in others.
1. Access is portable, I can just copy a xxx.accdb file to my company and continue with development.
2. Access is easy to generate helpful table, for example, it will automatically generate a field that can automatically count, could be used as primary key value.
3. it is more compatable with Excel, to display and filter data.
4. importantly, it nerely needs no environment to setup, just needs MS Office to be installed.
............others
However, I also find some points that MSSQL is advantaged:
1. security reasons
2. easy to backup, ( just use BACKUP..... sql statement to do it)
3. can edit stored procedure to save some functions to database
...............others
specifically, I wish some friends could tell me how to make other database portable? since I usually work both at home and in office. It's a headache to move MSSQL work to my office, since the version of MSSQL is not the same.
Thank you all and best regards, :)
Microsoft Access
I've never used Access, but the main disadvantage I'm aware of is that you have to have local filesystem access, which means:
You need a shared filesystem
Someone with write access can delete everything
It probably doesn't have very good multi-user performance due to file locking
(Someone correct me if I'm wrong about this)
Microsoft SQL Server
This is a pretty nice solution. I used it for several years and found it to be good in most cases.
Pretty good performance
Comes with a nice GUI (SQL Server Management Studio)
Integrates with Microsoft's domain logins (useful if you have Exchange I think)
There is a free version, but the non-free version is extremely expensive
MySQL
I don't recommend MySQL. PostgreSQL and SQL Server are both better in pretty much every way.
Good performance in some cases, extremely bad performance in others (terrible query planner)
Large community so it's easy to get help and tools
Free
PostgreSQL
Consistently good performance (able to use multiple indexes, has the best query optimizer I've ever used)
Somewhat arcane syntax in some cases and fewer tools (less new-user friendly)
Free
Conclusion
Since you're already firmly in the Microsoft camp, I'd just go with SQL Server, unless you're worried about price, in which case I'd go with PostgreSQL. Access is an option that may be easier upfront, but I think you'd end up regretting it.
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.
There is alot of talk at the moment about NoSQL from my understanding Mongodb is one of them, to me the NoSQL seems that it is SQL just not in the same sense that we know mySQL.
Think of it this way, they both store data, one does it by a fixed database with so called limits while another stores data when it thinks it the best time to store data and supposable has not limits or very few.
However this is confusing to web developers who are making the switch or thinking about making the switch. In my case I work for a big teleco company and making a switch like this is something that needs to be really looked at, and we cant relay on something that has no physical being so to say.
Maybe I am not understanding the meaning of NoSQL, maybe I have the meaning correct.
I am in the process at the moment re-writing the whole CMS that we use, and would kinda be nice to know should I spend the time looking at noSQL or keep MySQL (which does not seem to have any issues that the moment)
We only have 5000 rows in the customer details and in the backup with have 14000, it gets backed up just incase the master table decides to screw up.
Are you being forced to select one or another? If not, why limit the potential solutions of solving your business requirements by having to do 'this' or having to do 'that'. I equate the workflow steps of software engineering to those of a doctor.
A doctor has to make a number of decisions to ensure the operation goes successfully. This includes diagnosis, determining the incision points, and selecting the required tools of their trade; scalpel, bone-saw, etc. to complete the operation. If you told the doctor that they could only do the operation with a crossbow, the end results won't work out well for the patient or the doctor (malpractice).
So stepping away from the clumsy analogy, here are a few reasons why I opt to use both, (using an online bookstore as an example):
Book data such as ISBN, author name(s), dates published, etc. are stored in a RDBMS (let's say MySQL). By storing this type of data in MySQL I can run any number of queries to present to a user. For example, I can run a query returning you all books published by authors whose last name being with the letter Z, and a publish date of 2005, ordered by their ISBN descending. This type of data manipulation is critical when creating useful features for your company (or clients).
Book assets, such as cover art are stored on the filesystem using a NoSQL solution. This solves two problems. First, I don't want voluminous data ballooning up my MySQL database (blobs) so I'll store this data on the filesystem. And secondly, a book's cover art has nothing to do with any of the actual book data (people really going to want all books with the color blue in their cover art?). And we simply cannot forgo a book's cover art, as it could make or break a sale when a user is browsing our online inventory.
In closing, my recommendation to you is to select any and all the tools you need to finish the operation successfully, and in a way which makes it easy to add new features in the future.
With such data, MySQL wouldn't be a problem. NoSQL db are designed for large data sets, and are quite different designed(everything you can do in NoSQL you can also do in sql db).
Besides, NoSQL are far more harder to administrate. Cassandra needs right config to be faster than normal MySQL db, if not it is much slower(and even then you can have few problems with it). And for most NoSQL you need VPS/dedicated hostage.
NoSQL databases are worthy of some evaluation, but they have a niche that they suit and it's not CMS' with 5,000 rows.
I think you should stick with a proper relational, SQL-based database. You may find PosgreSQL to be a better free choice than MySQL, but you'll have to evaluate this yourself1.
1 There's a variety of resources for this, for instance: http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL.
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.
I know that both these databases are better for different scenarios but in terms of a website where users will login and enter numerical data to a daily log, which one would it be best to use? I read that mySQL is faster to begin with but PostgreSQL is more scalable if the website were to start getting a lot of users?
The downside is that my host only offers mySQL and so to use postgreSQL I would have to purchase VPS hosting which is more expensive. I have also read people advising people to not worry about it to begin with, however it concerns me that I would have to rewrite queries and forms if I later moved to postgreSQL? I would appreciate everyone's thoughts on this.
I don't understand why people have given this question negative marks when I clearly stated that I am from a finance background and only started learning 3 weeks ago. I think you need to remember that everyone has to start somewhere and that we haven't all been doing this as a job/hobby for years. I would love to see some of you come out of your comfort zone and come and do my job for a day as you would be equally as clueless and I can guarantee that I would not be so rude as some of you have been here. You should be trying to create an environment of learning and innovation, rather than an environment of arrogance. If everyone knew everything, what would be the point in this website?
Disclaimer: I have worked a lot more with PostgreSQL than with MySQL
From a performance/scalability point of view both are probably pretty much the same. There are workloads where Postgres is better and there are workloads where MySQL is better. Unless you test it in your environment it's hard to tell which one would work better for you.
Postgres seems (seemed?) to be faster in a workload with a lot of concurrent writes, whereas MySQL seems to be better with heavy read-only workload. But those benchmarks are about 3-4 years old now, so they are probably no longer true - especially since InnoDB in MySQL 5.5 improved a lot in that area.
However PostgreSQL's SQL features are far more advanced than MySQL's and MySQL has a tendency to silently ignore things you tell it to do - especially in a default installation (and if you rely on a foreign key to be created that might be a very unpleasant surprise). MySQL still has an advantage in terms of clustering as far as I can tell.
They are both equal when it comes to High Availability solutions.
I strongly disagree with the opinion that one should avoid any DBMS specific features - utilizing all features of a DBMS will make your application more scalable and will increase performance.
Traditionally MySQL wasn't known for stability and quality of their releases, but that seems to have improved since Oracle has taken over.
I still don't like MySQL's release policy where they introduce major changes and features in minor releases. The PostgreSQL dev team has a much more strict policy about what goes into a minor release. Upgrading a minor release (i.e. bugfix releases) is much less "dangerous" in PostgreSQL than it is in MySQL.
Someone once said the big difference between the PG development and MySQL is: the Postgres team first makes sure your data is safe, then it makes sure everything is working correctly, then it makes it fast. Whereas the MySQL team first makes it fast, then correct and finally stable. But that too might have changed since the Oracle takeover.
Personally I'd always prefer PostgreSQL over MySQL because of the much better SQL feature set and the overall quality of the product.
MySQL is the more popular solution and is used by very large companies for very large databases, so MySQL is far from unscalable.
If you want the ability to move between both databases at a later date in case you decide to switch, I would recommend using an ORM (Look at http://www.doctrine-project.org/); this way you'll only have to write the queries once and if you change to a different database down the road, you only need to change a config variable. Doctrine will also have you build your database structure in a YAML file which it can convert for you as well.
It's also capable of migrating between database types.
You'll also want to take into account the different MySQL Engines which perform differently as well. I was just looking at a comparison between PostgreSQL and MySQL which in their conclusion, they didn't like the fact that MySQL wasn't built with transactions, however, InnoDB does provide transactional support for MySQL as well as speed and memory improvements in some cases.
So the bottom line is this: If you can make your application in such a way that you can use either database (as mentioned above) run your own benchmarks against your application and your databases and see what kind of a difference it makes to you.
There's certainly other things to think about if you have the budget for it and that's getting DBA's specific to the database you're using and get them to optimize it.
First, SQL is SQL, be sure that you use strict SQL, then you don't rewrite anything. The different between the both dbs is the level of SQL support. PosgreSQL has better support, but the support by MySQL depends on the used storage engine.
Yes, you can better scale your application with PostgeSQL, but how mach load have you on your server? 1GB per day, less more?
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.