Isn't MySQL owned by Oracle? To each his own, but that would just about answer the question for me.
MariaDB isn't.
Ask HN: PostgreSQL or MySQL?
131–140 of 181 posts
Re: Ask HN: PostgreSQL or MySQL?
#132You don't really benefit from MySQL speed if you are not Facebook, so I would always start with PostgreSQL.
We use PostgreSQL but also Firebird, which maybe is the great underdog in opensource databases.
While not quite on topic, let me second that Firebird is a fine and under-appreciated RDBMS. Though it can obviously be used to run on your own server, it really shines when it's deployed in the field. It's used for desktop software I help maintain, running at several hundreds of small businesses. The install is super lightweight, requires very little configuration and practically zero maintenance. Firebird strikes a nice balance when it comes to features. What's great is that it can be used with or without a server process. That way you can start using it like SQLite and scale up to a more PostgreSQL-like setup, or go the other way, with no effort. Many years later, we're still very satisfied with our choice at the time.
Re: Ask HN: PostgreSQL or MySQL?
#1331. PostgreSQL. Fast, reliable, (relatively) small (for some reason mysql got a lot bigger). Had a few historic problems with replication but I think that's been resolved. I dealt a lot with large scale large data sets and I wouldn't recommend mysql for that at all, except if they were very simple and relations were either not used or used minimally.
There are better database systems than either, but I can't think of a less reliable one than MySQL.
If you use PHP though, mysql is easier.
(I'm going to assume the rest of the questions are SQL related and not SQLite, which is a particular binary format)
2. why? SQL + json would make some sense, sometimes. I haven't needed it - I just do SQL. Others have better answers.
3. There are tools to do some XML to and from SQL. YMMV. I always rolled my own.
4. it's always possible. Is it worth it? I used CSV with embedded json for a long time with archival storage because it was reversably parseable and could scale time-based databases somewhat reasonably. There are smarter ways to do this too ...
Re: Ask HN: PostgreSQL or MySQL?
#134Earlier quoted context omitted.
We use PostgreSQL but also Firebird, which maybe is the great underdog in opensource databases.
I used InterBase (Firebird predecessor) 15 years ago, and recall it had some big limits around versioning/lots of updates. To reclaim disk space we’d have to periodically backup/restore the db. It got so bad/frequent that we moved to Postgres and haven’t looked back since. I guess if one is considering SQLite that it’s not too relevant, but is this still an issue with modern Firebird?
Many of IB's limitations and bugs have been removed over the years. I think it was around FB2.5 that it really became a better product than IB ever was. A cool thing, though, is that it's very backward compatible. If you have applications that expect IB6, they will happily connect to any version of FB, even using the old client lib. The pace of development has ramped up since FB3, which was focused on rearchitecting the core. That's mostly a good thing. Still, I fear a little that it will also affect reliability.
Not sure exactly what kind of situation got you in trouble, but I haven't had any issues (ab)using the database myself. Disk space is still not reclaimed. It does, however, get used when the amount of data grows again, of course. Effectively the database is always the largest size it ever needed to be, but no larger. Most of the time, that shouldn't be any issue. If you expect huge spikes, there are other ways around it.
Re: Ask HN: PostgreSQL or MySQL?
#135Materialized views, common table expressions, outer joins, are all missing in mysql and essential. The Postgresql's stored procedure language blows mysql out of the water, and it's possible to use different language backends. SQLite has json extensions. You need to select them at compile time though, so you can't just assume they'll be there by default.
MySQL has supported left/right outer joins for as long as I can remember, and I've been using it continuously since 2003.
MySQL doesn't support full outer join, but it's rarely needed, and you can often get a similar result using a UNION. (Clunky, I'll admit... but I'd say the same thing about Postgres recommending against use of NOT IN, which is a common construct and more readable than an anti-join.)
CTEs were added in MySQL 8.0 (~1.5 years ago).
Agreed on the other points.
Re: Ask HN: PostgreSQL or MySQL?
#136MySql is the PHP of databases. Easy to get in to, but soon becomes a mire of pitfalls, exceptions, ambiguities etc.
PHP introduced me to the mindblow of having to use a lookup table to work out what the equality operators do under any particular combo of types and values. It was quite a rude shock even coming from C++.
Any properly designed language requires almost zero mental burden for equality. (Granted a longtime PHP guy will have it all memorised in time.)
MySql is in the same bracket. I was accustomed to commercial databases but my short stint with PHP also involved MySql, pre-MariaDB. Unless I'm on the point of starvation I'll not waste my efforts like that again.
Postgres, meanwhile, is a properly designed RDBMS and you can just get on with the job at hand.
Rather than having to constantly read the docs and go down the rabbit hole of MySql issues apparent from the endless comments about unexpected quirks and side-effects that used to be at the bottom of each doc page (which is likely the only reason that MySql was even usable and survived). Is it even yet ACID compliant?
I expect MySql will not be as bad for data analysis as it was for general development, but the reason it exists, in the face of Postgres, is because there are just so many devs and websites based on it. Similarly with PHP.
Re: Ask HN: PostgreSQL or MySQL?
#1371. PostgreSQL. Fast, reliable, (relatively) small (for some reason mysql got a lot bigger). Had a few historic problems with replication but I think that's been resolved. I dealt a lot with large scale large data sets and I wouldn't recommend mysql for that at all, except if they were very simple and relations were either not used or used minimally. There are better database systems than either, but I can't think of…
> I dealt a lot with large scale large data sets and I wouldn't recommend mysql for that at all
Was your use-case transaction processing (OLTP) or analytics (OLAP)? There are a ton of examples of massive-scale MySQL deployments for OLTP... Facebook, YouTube, Pinterest, Slack, Uber, Wikipedia, GitHub, Yelp, Etsy, Shopify, Booking.com, Wordpress.com, Tumblr, Box, Dropbox, Alibaba, Square, Venmo... a large chunk of the internet, in other words :)
Re: Ask HN: PostgreSQL or MySQL?
#138I'd say Postgres because of tools like https://hasura.io that let you automatically layer graphql on top of it and jsonb :)
Re: Ask HN: PostgreSQL or MySQL?
#1391. Whatever you feel most comfortable using and administering because the alternative is dangerous for production.
2. Probably.
3. Probably, but you'll probably have to write the code to do it.
4. Why bother?
Re: Ask HN: PostgreSQL or MySQL?
#140Answering Q1: MySQL over Postgres. Postgres has 2 critical things going against it - The query optimizer is a mess - It's implementation of secondary indexes is not cache friendly, so it can be slow
I don't know what you're trying to say. PostgreSQL makes no distinction between primary and secondary indexes. MySQL, which only knows clustered indexes (see "Unreasonable Defaults" [1]) has to make such a distinction, so that when you use a secondary index it also has to go through the primary index in addition to the secondary index. Also
[1] https://use-the-index-luke.com/blog/2014-01/unreasonable-def...