3 ms·

> They had begun work in 2011, but they rejected all of the existing document databases (such as MongoDB or Riak). In 2013 they decided to work on version 2.0 o

> They had begun work in 2011, but they rejected all of the existing document databases (such as MongoDB or Riak). In 2013 they decided to work on version 2.0 of their software, which would be a complete re-write, but they decided to continue to keep JSON strings in PostGres. That's speaks in their favor, in my opinion. We actually consciously moved the way MongoDB -> PostgreSQL JSONB column, and are pretty happy with that. Sorry, original author, but if you recommended us to use shiny new databases like MongoDB or Riak, we'd probably think of you as a young and inexperienced engineer. Although I agree about Design Patterns. For example, you'd use/no use ReactiveX regardless of whether you know about Observer pattern or not.

crb002 9y ago
The #1 enginering design pattern is to obey speed of light transfer of information latency. Moving data into and out of MongoDB has that unavoidable cost, and it is a waste if the only thing you want is JSON formatting of the same data already in your RDBMS.
- Shikadi 9y ago
  >Speed of light transfer of information latency That's not a thing, at least not in this context or that phrasing.
- Retra 9y ago
  That's not a design pattern, it's just a constraint that designs have to account for.
- b4lancesh33t 9y ago
  Overall latency is important. Where it comes from isn't very important. Transferring data a few light-nanos of distance into or out of a colocated Mongo DB instance simply isn't going to move the needle on any important metric. (Disk IO latency might, but that has little to do with the speed of light.)
tomca32 9y ago
I believe his complaint isn't about not using MongoDB, but about storing JSON as strings in a database that supports actual JSON(B) data type. As you said yourself, you migrated to PG JSONB columns, not to PG Text columns for storing JSON. So it seems to me that you agree with the author.

crb002 9y ago

The #1 enginering design pattern is to obey speed of light transfer of information latency. Moving data into and out of MongoDB has that unavoidable cost, and it is a waste if the only thing you want is JSON formatting of the same data already in your RDBMS.

Shikadi 9y ago
>Speed of light transfer of information latency That's not a thing, at least not in this context or that phrasing.
Retra 9y ago
That's not a design pattern, it's just a constraint that designs have to account for.
b4lancesh33t 9y ago
Overall latency is important. Where it comes from isn't very important. Transferring data a few light-nanos of distance into or out of a colocated Mongo DB instance simply isn't going to move the needle on any important metric. (Disk IO latency might, but that has little to do with the speed of light.)

tomca32 9y ago

I believe his complaint isn't about not using MongoDB, but about storing JSON as strings in a database that supports actual JSON(B) data type. As you said yourself, you migrated to PG JSONB columns, not to PG Text columns for storing JSON. So it seems to me that you agree with the author.