News for hackers. Stuff that matters.

A comment on RethinkDB Postmortem. Parent comment

Re:RethinkDB Postmortem by jhchen on Wednesday January 18, 2017 @01:31AM (#13424517)
Why is optimizing for SSDs nonsense? Empirically this seems correct since RethinkDB themselves pivoted away from this but curious about the technical explanation.
[ Parent | on HN ]
Re:RethinkDB Postmortem by Plugawy on Wednesday January 18, 2017 @02:32AM (#13424747)
coffeemug explained it himself in a podcast where he was interviewed about Rethinkdb (I don't remember the name of the podcast). Basically it boiled down to the fact that all existing databases (at that time) could be tuned with very little effort to take advantage of SSDs so that differentiating factor flew through the window
[ Parent | on HN ]
Re:RethinkDB Postmortem by joshberkus on Wednesday January 18, 2017 @10:58AM (#13427241)
Exactly.
[ Parent | on HN ]
Re:RethinkDB Postmortem by dkersten on Wednesday January 18, 2017 @06:39AM (#13425657)
RethinkDB themselves pivoted away from this

I believe the storage backend remained largely the same (ie current RethinkDB, IIRC, is still optimised for SSD). Maybe I'm mistaken.

[ Parent | on HN ]
Re:RethinkDB Postmortem by SamReidHughes on Wednesday January 18, 2017 @11:06AM (#13427332)
It's the same storage backend (well, modified quite a bit) and optimizing for SSD's isn't really the goal anymore, especially since things are now stored in a file and not the whole block device, and O_DIRECT is turned off.
[ Parent | on HN ]