It seems to me that the success of MySQL can be tied directly to people using "database" for things where what they really need is "filesystem".

Great, you've just invented a half-assed DBMS.

My first thought is "Yeah, we already have one of those, it's called MySQL"

The success of MySQL can be tied directly to people using "database" for things where what they really need is "network filesystem".

The success of SQLite can be tied directly to people using "database" for things where what they really need is "filesystem".

Interesting that it's the same dynamic at play.

http://www.reddit.com/r/programming/comments/1niheb/mongodb_...

Why? I can't see one feature that MySQL delivers better than Pgsql...

PostgreSQL is a pain to setup, the SQL parser is very finnicky and for the past times I spent too much time trying to work around every idiosyncrasy of Postgres when I could have a similar MySQL instance running in a shorter time

So, MySQL doesn't waste my time with stupid crap.

Now please call me ignorant and downvote me since PostgreSQL fanboys can't take a critique and think their loved database is perfect.

However, one common use case (for me) is having to have a one-off install, which unfortunately kind of prevents that.

If my job needed frequently installs of DBs I would have probably gone this way, but it isn't, so today it's PostgreSQL 9.1 on Mac OS, tomorrow (more likely, a year or two from now) it's MySQL on Fedora, etc

My experience has been running on Slackware/RedHat/Ubuntu, though, and never on any Windows version, if that matters.

I really like how all values in the SQL in PostgreSQL can be replaced with arbitrary expressions, including stored functions. YMMV.

What is an hba file? How am I supposed to know what it does?

PostgreSQL has a "createuser" command. Great, but how am I supposed to know this is a PSQL command? (not to mention potential collision with other filenames)

RTFM? This is an acceptable answer, but it disregards completely the user experience.

MySQL is more intuitive. Authentication? User/password. None of this "ident" or "trust" (really?) schemes. Yes, pg_hba is more flexible, but if you have only one DB user... Yes, it's convenient to have a local "trust" connection. Also a little bit more insecure as well.

And there are convenient mysql* commands, you can tell they are mysql commands.

From the section in the docs titled "the pg_hba.conf file", which explain it quite clearly? [1]

> PostgreSQL has a "createuser" command. Great, but how am I supposed to know this is a PSQL command?

Its not a psql command, its a client application. Which you are expected to know by reading either the documentation section on client applications [2] or the documentation on the administrative function for which that particular application is used [3].

Of course, you don't need the program for the function, you can just use SQL. Which, presumably, you are going to be reading the documentation on for any RDBMS, since even the ones that support the standard the best (e.g., between PostgreSQL and MySQL, PostgreSQL by far) still have some implementation specifics you need to be aware of.

> MySQL is more intuitive. Authentication? User/password.

PostgreSQL supports that, and configures it by default in the project-supplied installers (IIRC, for local connections only by default.) You only need to configure authentication if you are using different options, or want to support remote logins.

> Yes, pg_hba is more flexible, but if you have only one DB user...

You don't need a multiuser RDBMS at all?

> And there are convenient mysql* commands, you can tell they are mysql commands.

And how do you know that they exist or what they do without reading the docs?

[1] http://www.postgresql.org/docs/9.3/static/auth-pg-hba-conf.h...

[2] http://www.postgresql.org/docs/9.3/static/reference-client.h...

[3] http://www.postgresql.org/docs/9.3/static/database-roles.htm...

"(createuser) not a psql command, its a client application."

Yeah, so postgresql is the only program that creates users for itself? Createuser is a generic name.

(Some) Postgresql client appplications have no prefix. MySQL apps have.

So that if I see a file called mysqladmin I know it's from mysql. If I see a file called createuser I don't have that information. Who says it's from pgsql and not somebody else?

> And how do you know that they exist or what they do without reading the docs?

mysql <TAB>, then man or --help?

The CREATE USER issue is just bad faith on your part. It is a de-facto standard, used by Oracle, Transact-SQL and ironically MySQL.

In the end, your complain boils down to:

1. Having to edit pg_hba replacing "ident" with "password"

2. Unfamiliarity with pgsql opposed to familiarity with mysql

A developer that chooses tools primarily based on familiarity is on the slippery slope to dinosaur land. Not that it's bad -- Cobol development still pays well to this day.

"A developer that chooses tools primarily based on familiarity "

Yes, let me waste time to learn how to use the latest fad on HN, sure (not talking about PostgreSQL here)

And PostgreSQL is made of unicorn blood and my projects will be 200% better if I use it instead of MySQL, sure.

It's a DB. There's a narrow range where it would make a difference to use it instead of scaling to more servers, for example. And you can "always" convert later. (Unless you're FB apparently)

I will definitely grant you that mysql is easier to use than postgres if you're only willing to read the docs for one.

As for the parser being finnicky, that is a feature. Hint: an empty string in a timestamp does not mean midnight 1/1/1970. This is one area where mysql did more harm than good: getting developers hooked in sloppy SQL.

I've installed it on Linux and Windows and, no, its not. Its pretty much the same work as MySQL to setup, except the install usually wants information to create or use a system user for the DB server in the install, which is a trivial amount of extra work.

I understand this used to be an issue many years ago (IIRC, most of the streamlining of the setup happened in the first couple of major 8.x releases, in 2005-2006, about the same time as official native Windows support was added.)

> the SQL parser is very finnicky

How so?

In what way is it finicky?

For example, MySQL accepts both ' and " as string delimiters. It's very fun trying to get around PGSQL not understanding what you want to do while MySQL understands.

It doesn't require ';' to mark the end of a command

That is, in its default mode, MYSQL does not accept ANSI-standard quoted identifiers (supporting only non-standard use of backquotes for quoted identifiers), and instead treats double quotes as equivalent to single quotes for strings. (Of course, MYSQL has a non-default option to support the standard.)

PostgreSQL, OTOH, supports the standard out of the box, and treates double quoted material as quoted identifiers.

Neither behavior is more finnicky, one is just standards-compliant.

> It's very fun trying to get around PGSQL not understanding what you want to do while MySQL understands

This would appear to only be an issue if your only RDBMS experience is with MySQL and you are adapted to its quirks, since if you have experience with other DBs which adhere to the ANSI standards for basic behavior, MySQL will, by default, be more likely to not understand what you mean than PostgreSQL.