Good summary, agree 100%. >From experience, Postgres is amazingly configurable, if you ever want to do something weird. Sqlite is too, but only if you access it directly in C and don't really need a server.
And the guys working on the internals (both) are the smartest bunch you're likely to run across any time soon. And they answer questions and fix bugs. Both are highly recommended, if you don't have a compelling (vendor) reason to use Oracle, MSSQL or DB/2. It's not obvious why the others exist. Regards David M Bennett FACS Andl - A New Database Language - andl.org > -----Original Message----- > From: sqlite-users-boun...@mailinglists.sqlite.org [mailto:sqlite-users- > boun...@mailinglists.sqlite.org] On Behalf Of Darren Duncan > Sent: Monday, 30 May 2016 1:45 PM > To: SQLite mailing list <sqlite-users@mailinglists.sqlite.org> > Subject: [sqlite] Postgres vs MySQL (was Re: Messages posted on Nabble not > getting to list) > > On 2016-05-28 12:49 PM, r.a.n...@gmail.com wrote: > > @Daren > > > > Any reasons for the thumbs down on MySQL? Their workbench is better that > Toad ... > > > >> On May 27, 2016, at 10:00 PM, Darren Duncan <dar...@darrenduncan.net> > wrote: > >> > >>> On 2016-05-27 2:28 PM, Balaji Ramanathan wrote: > >>> But when I was debating between MySQL and SQLite for my project, I > >>> almost didn't choose SQLite because of the archaic look and feel of > >>> the sqlite.org website and support options available there. > >> > >> For the love of all that's good, don't choose MySQL for anything. If > >> you want something bigger than SQLite, look at Postgres instead of > >> MySQL. As a bonus, the Postgres documentation is much better. -- > >> Darren Duncan > > r.a.nagy, > > My judgement is based primarily on the DBMS server itself, which is the > product being compared, not on separate client programs. (And each DBMS has > multiple clients that work with it.) > > For practical decision purposes, Postgres and MySQL both compete in the same > space as each other, multi-user client-server DBMSs. This is a different > space than SQLite competes in. If you're doing a task appropriate to the > space SQLite is in, I recommend using SQLite. If you're doing a task > appropriate to a multi-user client-server DBMS, I recommend for Postgres and > against MySQL. > > Comparing the two... > > Postgres is a high-quality project with a semi-regular predictable release > schedule and has a strong emphasis on good quality and good security, being > as bug-free as possible and in not losing data. Postgres has an order of > magnitude of more, useful, features, and gains a lot more that people can > notice each year. Its design decisions make more practical sense and it > strives to be a lot more compatible with the SQL standard where that makes > sense. In summary, it has tons more features people actually use and find > valuable, and it has a strong emphasis on keeping the quality up. When > relatively rare bugs or security issues do occur, they are fixed promptly and > clear documentation is given on how to mitigate or recover from the problem. > Postgres also has better general user documentation. Postgres even has > useful features that Oracle doesn't have. Postgres also has expert level > support from multiple companies, and its BSD license (almost like public > domain but not quite) means it can be used in any applications without a > special license. > > MySQL is a lower-quality project that has historically focused more on user > bases that don't put as much importance on the quality or persistence of > their data and want to use the DBMS more as a dumb data store with most work > done application-side. MySQL has an order of magnitude fewer useful > features, often lacking things that are quite valuable in practice, and a lot > of the features it does have carry various gotchas or strange behaviors. As > such, performing a lot of tasks is more difficult or not possible without > excessive circumlocution, and users are more likely to see wrong answers or > data loss due to either unexpected behaviors or bugs. MySQL is notorious for > shipping half-baked code to production, see version 5.1 in particular. MySQL > is also notorious for going a long time claiming that particular important > features are not important. This includes a number of features that even > SQLite has long had. MySQL also has gone a long time without perceptively > adding new features with much significance. Their main advance in features > was between versions 3 and 5.1, the last being a decade ago, and since then > have mostly talked more about things like speed enhancements and not much on > interesting features. The MySQL documentation isn't as good. MySQL has a > twin GPL/proprietary license so you need to pay Oracle lots of money if you > want to use it in some applications, and Oracle doesn't have as much > motivation to make it a contender when they have their other bread and butter > DBMS to compete with. > > So MySQL is decently suited say for running stuff like blogs or message > boards, while if you want to do something important like run a financial > accounting system or medical database, Postgres should be used instead. > > This assumes applications warranting client-server. SQLite should also be > used instead where it makes more sense, and SQLite is much more thorough > about quality and being bug free than Postgres, with its 100% code coverage > test suite and all. > > -- Darren Duncan > > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
