(not a rebuttal on your comment, just a continuation of the conversation)
I found it an interesting criticism, and from what we know about the project I don't think I agree with the author.
In the space of what database to use, there are really few differences between Postgres and Postgres' peers, that "using what's available" is a perfectly sound reasoning to use Postgresql over, say, MySQL. I think around that time MongoDB was a possible alternative as well, however it was experimental and often mocked. Postgres and Mysql are pretty much feature parity, even in 2011, except for very niche use cases, which this project did not sound like it would have.
Factoring in that Heroku's PG UI is great, and to use an alternative would mean to have to set things up yourself (in 2011 the Heroku marketplace was not yet as expansive iirc), or at least have another account at another SaaS company with dubious maturity, the decision to use PG seemed to have been given the correct amount of critical thinking ("will it be able to support all that we need? most likely yes").
The author may also not have been aware that for RoR applications the code is pretty DB-agnostic, an unawareness he hints at in other parts of the story as well. Meaning that in the span of the year that they're working on rebuilding the site in RoR, if they discover a use case that another DB would be extremely helpful with, they could relatively easily switch over to this other DB without having to rewrite all of the code. At most it'd take rewriting of some migrations for FK's and possibly some (hopefully few) custom SQL queries. Remember that they had a one-time-switch-over when the site was done being built, so during this year of development time, the database did not accrue live user data that would have made such a change more difficult.
You’re not wrong in your assessment but I would still expect a company architecting a total replacement for an existing system to know why they are choosing critical components. In this case it was an extensive lack of database consideration in many decisions.
I found it an interesting criticism, and from what we know about the project I don't think I agree with the author.
In the space of what database to use, there are really few differences between Postgres and Postgres' peers, that "using what's available" is a perfectly sound reasoning to use Postgresql over, say, MySQL. I think around that time MongoDB was a possible alternative as well, however it was experimental and often mocked. Postgres and Mysql are pretty much feature parity, even in 2011, except for very niche use cases, which this project did not sound like it would have.
Factoring in that Heroku's PG UI is great, and to use an alternative would mean to have to set things up yourself (in 2011 the Heroku marketplace was not yet as expansive iirc), or at least have another account at another SaaS company with dubious maturity, the decision to use PG seemed to have been given the correct amount of critical thinking ("will it be able to support all that we need? most likely yes").
The author may also not have been aware that for RoR applications the code is pretty DB-agnostic, an unawareness he hints at in other parts of the story as well. Meaning that in the span of the year that they're working on rebuilding the site in RoR, if they discover a use case that another DB would be extremely helpful with, they could relatively easily switch over to this other DB without having to rewrite all of the code. At most it'd take rewriting of some migrations for FK's and possibly some (hopefully few) custom SQL queries. Remember that they had a one-time-switch-over when the site was done being built, so during this year of development time, the database did not accrue live user data that would have made such a change more difficult.