[hot_gril]

Not gonna lie, seeing him ditch Mongo for Postgres then say "API calls generally take 8 ms now, not 150 ms" made me a little happy. Mongo can make sense, but it seems like he was thoroughly on the hype train for it rather than actually needing it.

[pachouli-please]

In the article, he mentioned that working in JSON seemed natural and comfortable. So after checking to be sure mongo was fairly mature and commonly used, went with it.

Sounds reasonable and not hype train driven

[hot_gril]

Postgres had good JSON support in 2019, and he later realized JSON wasn't actually needed. Hype train is what made MongoDB a default recommendation when it's really a more niche option.

[hot_gril]

(To be clear, I'm not saying the author was hyping up Mongo, just that the hype got to him.)

[dizhn]

It sounds reasonable as one of the options to try.

[DaiPlusPlus]

> he mentioned that working in JSON seemed natural and comfortable

As opposed to?

[cyclotron3k]

I've heard it said that the best no-sql database is Postgres

[hot_gril]

The real point of NoSQL is to enable horizontal scaling, which is probably irrelevant to the author's use case.

[brimstedt]

Id say the point of nosql is rather "the right tool for the job".

You can use an SQL db engine as a kv-store, but you can probably make a more efficient kv-store if you do not have the SQL constraints.

(Oth SQL engines are pretty efficient for lots of use cases these days)

Another example where SQL may not be the right choice is time series or graph DBs.

[hot_gril]

Postgres might even be a more efficient KV store than Mongo, just not as scalable beyond a single machine.

[re-thc]

i.e. the best no-sql is sql!