[tesmar2]

I think it really depends on the type of apps you write. If you write small - medium rails apps, then the db is usually just dumb storage and if you are careful to use the ORM properly, then DBs are just plug and play. If your app is larger and you need more features, then you look more deeply into the features of each in which, most of the time, POSTGRES is the clear winner.

[VLM]

"If you write small - medium rails apps"

If you are writing using a MVC like rails, mysql is easier because the M is solely in the rails app rather than some of the M being in the rails and some of the M being in the DB configuration.

Theoretically there's no postgresql issue if you're comfortable splitting design and config stuff into two areas is acceptable IF all the devs are also DBAs, or if you are careful to never use any of the features of postgresql (turning it back into a persistent store), or if you never use any of the model features of rails to enforce data constraints, or if the DBA and the DEVs are on exactly the same page... adding a spinlock like that across functional areas, or maybe even across departments, is rarely a win.

[fdr]

For many small Rails web applications, details having sane (and rich) datetime support in the database is both nearly invisible (turning bugs into errors, and working about the same otherwise) and very useful. The same could be said about silent truncations of strings (one can get the same behavior in Postgres by using a explicit cast, or just a built-in function).

LedgerSMB -- an author of which wrote this article -- is on the advanced side of the spectrum in using specific Postgres-isms, and that's not for everyone.

There are grades in-between: using arrays for simple kinds of matching in Postgres is not rocket science and can make your life a lot easier (and faster):

  SELECT * FROM blawg WHERE tags && '{a,b,c}';

Yet another use case might be full-text search, where integrating and synchronizing an external information retrieval system (like Lucene, Solr) for simple search use cases are just more trouble than it is worth. With slightly more work than the above, one can use Postgres's Full Text Search feature.

So here I think you are supposing a false dichotomy: there is a continuum available on both databases, but the continuum extends a lot more into 'the database can know something about the data' territory in the Postgres implementation.

[einhverfr]

Certainly it isn't for everyone.

The thing is, LedgerSMB aims to be a database for many apps. You can't do that and still have an app that runs on many databases.

I am not convinced that grades in between are all that great. I think you have to choose the degree of portability you want first and the level of db-as-api you want first and then program to that.

[einhverfr]

On top of that, if all you are doing is relatively simple persistence, the sql_mode and plugin table model can be actually very useful even though these get in the way in some other environments.