4 ms·

These articles never get old. Hey we picked solution A and realized that it has some cons not only pros and now we are moving to solution B that only has pros.

These articles never get old. Hey we picked solution A and realized that it has some cons not only pros and now we are moving to solution B that only has pros. Few years later there is a new article, hey we are moving to solution A|C because...

smt88 6y ago
I've never seen an article about switching from Postgres to something else. Obviously Citus, Timescale, and other Postgres forks don't count. Uber did one a while ago, but tl;dr they didn't really understand Postgres very well and were dealing with unique problems.
- philliphaydon 6y ago
  I'm not sure they understood the problem they were trying to solve let alone understood Postgres.
- StreamBright 6y ago
  I have seen Uber ping-ponging between Postgres and MySQL. My approach to this problem is, can we use Postgres? If the answer is yes (90% of the cases) we use Postgres. If the answer if no investigate what is good out there. For k:v I have used Riak with much satisfaction. For distributed databases we are experimenting with TiDB. It looks very promising so far. There is only one problem with Postgres that I run into. Client connection scalability. This is why many users use a connection proxy in the front of it.
jspash 6y ago
I find them quite useful. Especially if I've never used technology A. After a while you start to see a pattern of people with similar problems to yours moving away from a certain tech. If it weren't for articles like these, we'd all be making the same silly mistakes over and over again. Collective hindsight is a powerful thing and we should use it to our advantage to short-circuit certain problems. If only politics worked that way :/
kumarvvr 6y ago
And I wish they never get old. Every few years, new paradigms come to the forefront and debates like these certainly help many developers choose one way or the other.
- StreamBright 6y ago
  In what paradigm are you referring to exactly with Postgres and Mongodb? Relational turning 51 years old in 2021 while key-value stores category (which MongoDB falls into) is at least 40. So in a sense this article is about which technology should we use, a 40 or a 50 years old one?
  - asya999 6y ago
    MongoDB is not a key-value store. It's a document database.
    - StreamBright 6y ago
      "Document-oriented databases are inherently a subclass of the key-value store, another NoSQL database concept." https://en.wikipedia.org/wiki/Document-oriented_database https://en.wikipedia.org/wiki/Document-oriented_database
  - kumarvvr 6y ago
    The paradigm of which type of database is best suited for large scale data, distributed in different locations.
vorticalbox 6y ago
here is one from Last year where HSBC bank has moved all its 65 SQL databases into a single MongoDB. https://diginomica.com/hsbc-moves-65-relational-databases-one-global-mongodb-database https://diginomica.com/hsbc-moves-65-relational-databases-on...
wilco_vd 6y ago
I was one of the developers on the team that wrote that article. The main point of the article was (and still is) not that PostgreSQL is better than MongoDB, but that PostgreSQL suited us better at that point. In hindsight I think it suited us better because MongoDB was relatively new tech, PostgreSQL was more mature. Especially if it came to tooling and diagnosis on -what- is going wrong when things go wrong, as well as searchable help on the internet. The extra maturity of PostgreSQL allowed us to learn faster and evolve our software faster with less surprises. As a small team in a start-up this was essential to us. Considering other articles on that "picked a solution and didn't understand it well" - I do thing they are very valuable. They provide an insight on how well frameworks and technology support a learning curve. It's not about having only Pro's. it's about how easy it is to get yourself unstuck if you engineered yourself in a corner where you don't want to be.

smt88 6y ago

I've never seen an article about switching from Postgres to something else. Obviously Citus, Timescale, and other Postgres forks don't count. Uber did one a while ago, but tl;dr they didn't really understand Postgres very well and were dealing with unique problems.

philliphaydon 6y ago
I'm not sure they understood the problem they were trying to solve let alone understood Postgres.
StreamBright 6y ago
I have seen Uber ping-ponging between Postgres and MySQL. My approach to this problem is, can we use Postgres? If the answer is yes (90% of the cases) we use Postgres. If the answer if no investigate what is good out there. For k:v I have used Riak with much satisfaction. For distributed databases we are experimenting with TiDB. It looks very promising so far. There is only one problem with Postgres that I run into. Client connection scalability. This is why many users use a connection proxy in the front of it.

jspash 6y ago

I find them quite useful. Especially if I've never used technology A. After a while you start to see a pattern of people with similar problems to yours moving away from a certain tech. If it weren't for articles like these, we'd all be making the same silly mistakes over and over again. Collective hindsight is a powerful thing and we should use it to our advantage to short-circuit certain problems. If only politics worked that way :/

kumarvvr 6y ago

And I wish they never get old. Every few years, new paradigms come to the forefront and debates like these certainly help many developers choose one way or the other.

StreamBright 6y ago
In what paradigm are you referring to exactly with Postgres and Mongodb? Relational turning 51 years old in 2021 while key-value stores category (which MongoDB falls into) is at least 40. So in a sense this article is about which technology should we use, a 40 or a 50 years old one?
- asya999 6y ago
  MongoDB is not a key-value store. It's a document database.
  - StreamBright 6y ago
    "Document-oriented databases are inherently a subclass of the key-value store, another NoSQL database concept." https://en.wikipedia.org/wiki/Document-oriented_database https://en.wikipedia.org/wiki/Document-oriented_database
- kumarvvr 6y ago
  The paradigm of which type of database is best suited for large scale data, distributed in different locations.

vorticalbox 6y ago

here is one from Last year where HSBC bank has moved all its 65 SQL databases into a single MongoDB. https://diginomica.com/hsbc-moves-65-relational-databases-one-global-mongodb-database https://diginomica.com/hsbc-moves-65-relational-databases-on...

wilco_vd 6y ago

I was one of the developers on the team that wrote that article. The main point of the article was (and still is) not that PostgreSQL is better than MongoDB, but that PostgreSQL suited us better at that point. In hindsight I think it suited us better because MongoDB was relatively new tech, PostgreSQL was more mature. Especially if it came to tooling and diagnosis on -what- is going wrong when things go wrong, as well as searchable help on the internet. The extra maturity of PostgreSQL allowed us to learn faster and evolve our software faster with less surprises. As a small team in a start-up this was essential to us. Considering other articles on that "picked a solution and didn't understand it well" - I do thing they are very valuable. They provide an insight on how well frameworks and technology support a learning curve. It's not about having only Pro's. it's about how easy it is to get yourself unstuck if you engineered yourself in a corner where you don't want to be.