Why was the RethinkDB chosen as DB for the DeviceFarmer?

[ConfusedMerlin]

Greetings,

this time I have a question about a design choice: why do you use a rethinkDB for your core database?

I am a bit firm in postgreSQL and, after I had to revive our DeviceFarm's rethinkDB, in that too. But recently I was asked why the Devicefarm does use a RethinkDB and not a PostgreSQL... and wasn't able to answer that.

That question came from the "monitoring department", which seems to be unhappy that they can't monitor the RethinkDB not as good as a PostgreSQL (something about limited recordsets and the document based structure). Also, a ticked was already spawned in which it's requested to switch to a PostgreSQL

But I am lacking any useful arguments, beside that it is a huge undertaking and would require a fork from your repository. So, beside the work necessary to switch to another DB, what does the RethinkDB offer that makes it the best choice for the Devicefarm?

[denis99999]

@ConfusedMerlin ,
This choice is historical and goes back to the initial OpenSTF project, I guess rethinkdb was chosen because of all the advantages offered by noSQL databases precisely.

In addition, you should know that the device reservation system relies heavily on the "changefeeds" mechanism of rethinkdb, to see if this is available in postgreSQL?

In any case, postgreSQL support could be considered but as an alternative and not as a replacement for rethinkdb.

[ConfusedMerlin]

@denis99999 , thank you for your information.

I will try to present this the next time the question of db change comes up and - if time allows it - have look at the changefeeds topic.

Still, I have to admit that I do not understand that last sentence; what is the difference between an alternative and a replacement in that context? If one wants to use the alternative, he would have to replace the current db in his fork of the project, wouldn't he?

[denis99999]

This means that rethinkdb should be kept as STF's default database due to all the advantages of this type of database, but also the current fleet deployed by all STF customers.

Also, I confess that I'm personally not a big fan of SQL databases, but if such a database were to be supported, it would require a deep rewrite of the STF code which is very much closed to rethinkdb, providing an abstract interface allowing switching to the chosen database type, also assuming that this database type integrates rethinkdb's "changefeeds" mechanism.

So at present, given the complexity of such development with the risks it means to existing deployments and considering that obviously your need to migrate to postGreSQL is only driven by internal considerations to your company and is not a generic need, the best in this case for you is effectively as you say to fork the STF project to implement your specific need.