15 ms·

Migrating from RethinkDB to Postgres – An Experience Report

135 points by okket 9y ago

hmottestad 9y ago
"Postgres is basically going to be around forever". My favourite quote from the article and a really great point. Even with RethinkDB going opensource there's only been one single release in the last year, and it was a bug fix release.
- noncoml 9y ago
  With RethinkDB and Basho going out of business, it has an interesting year for databases. I think we are seeing the dawn of the new databases golden era, and the world is converging to 3-4 databases, that is Postgres, Cassandra and Mongo and ElasticSearch.
  - paxy 9y ago
    MySQL still has massive usage, and isn't going anywhere.
    - noncoml 9y ago
      Agreed, I meant other than Oracle, MySQL/MariaDB and MSSQL, which are the top 3 anyway.
thecopy 9y ago
I am beginning to see a trend on HN. Teams are moving away from new and young databases to old and "boring" databases as their need for stability and correctness increases.
- pjmlp 9y ago
  Which is why we grey beards just wait for the caravan to pass until the dust settles, then we get back to action and recover our dues.
- dm3 9y ago
  Would be interesting to hear how they arrived at the RethinkDB/Elasticsearch combination over Postgres at the start of the project. It doesn't seem they lost any features after the transition. Was something lacking in Postgres at the time of initial implementation?
  - chris_st 9y ago
    However, they do say: > leaning heavily on Haskell in order to fill in some of the gaps quickly. So it looks like they had to do some work to cover some features from rethinkdb/elasticsearch.
    - fmap 9y ago
      The code in the post is just used to migrate from an untyped interface to a typed one. Unless I'm missing something, there seems to be no mention of any missing features in postgres.
      - Yeroc 9y ago
        They did mention missing JSON schema validation in Postgres.
        billrobertson42 9y ago
        And also many mentions of no schema validation in Rethink, so that's probably not a gap.
- deleted 9y ago
  [deleted]
- Thaxll 9y ago
  hmm not really, it doesn't make any sense ( text search included ) to put everything into PG. PG doesn't even have a clustering solution out of Citus, how do you scale / HA postgres using the default setup without doing sharding yourself?
  - X86BSD 9y ago
    What? There are over a dozen. See: https://wiki.postgresql.org/wiki/Clustering https://wiki.postgresql.org/wiki/Clustering Some commercial.
    - Thaxll 9y ago
      Those are third parties extensions, ES does clustering out of the box well. Most of the thing on your list don't have proper clustering solution built-in which means you have to support it yourself.
      - X86BSD 9y ago
        You said that PG had no clustering solutions, I showed you there were. Some of them may require more work than others but there ARE clustering options none the less for PG. It's inaccurate to say there are none.
fiokoden 9y ago
Postgres is always the answer.
- qaq 9y ago
  Well not always but for a wast majority of cases it's a very strong option.
- virmundi 9y ago
  No it's not. It's question dependent. "Would you like a burrito?" "Postgres". See? It doesn't work.
  - jacquesc 9y ago
    Works for me. I'd probably lose weight if I started using that answer.
  - sin7 9y ago
    Pos que cres? (What you think?) Seems like a legit answer to me.
yipopov 9y ago
I've had a prodigal son moment with Postgres myself. I found that even for many tasks that seem to favour NoSQL (time series, etc.) you get lot more bang for the buck in terms of performance for the same resource usage with Postgres.
firasd 9y ago
Interesting quote: "we decided to compute all statistics on demand. This was something we previously tried in RethinkDB, but the results were not good... When we tried implementing statistics as SQL queries in Postgres, we were amazed by the performance. We could implement complex statistics involving data from many tables." I think standard line "use right tool for the job" is still the ultimate answer. Data in most applications is relational, and you need to query it in different ways that weren't anticipated at the beginning, hence the longevity of SQL. That said, I too often see HN commentators say something like "this data was only 100 GB? Why didn't they just put it in Postgres?" which is not as clever as the writer may think. Try doing text search on a few million SQL rows, or generating product recommendations, or finding trending topics... Elasticsearch and other 'big data' tools will do it much quicker than SQL because its a different category of problem. It's not about the data size, it's about the type of processing required. (Edited my last line here a bit based on replies below.)
- qaq 9y ago
  We do exactly what you describe on about 80TB dataset stored across a number of PG instances. The 100GB comments are extremely clever because running a query against a dataset that fully fits in RAM will be blazingly fast. "Try doing text search on a few million SQL rows" we are doing it on billions of rows.
  - probablybroken 9y ago
    I think some of this can be attributed to expectations; Many systems such as elastic are expected to run on ram, whereas people tend to expect relational systems to perform reasonably well on disk. I think we all want a magic black box that makes such problems disappear, and we always seem to be disappointed with the system in question when at some point it doesn't.
    - qaq 9y ago
      You are 100% right the perpetual search for "magic black box" is the cause of much pain on the bright side it's also a source of significant amount of high paying work to clean up the mess.
cyberferret 9y ago
> Rethink is no longer commercially maintained. Just wondering, seeing as am not a Postgress user - is Postgress commercially maintained? Or is it pure open source (like I believe RethinkDB is currently)?
- detaro 9y ago
  Postgres is Open Source, but multiple companies sell support, employ devs and/or provide distributions of it.
- sbuttgereit 9y ago
  There is no single company behind PostgreSQL, there's a foundation which manages development, but there are a number of well established businesses offering commercial grade support. Some of these companies employ some of the major contributors to PostgreSQL.
  - rwmj 9y ago
    Wasn't there in fact an agreement amongst the PostgreSQL contributors that they'd never all go and work for the same company?
    - sbuttgereit 9y ago
      I'm not sure (others here, naturally, may be in the know). Having said that, there do seem to be some larger concentrations of them in a few companies. I don't keep up too much with that either, but it seems like EnterpriseDB was in this camp (and logically so). I do think there are enough companies now that develop PostgreSQL based products (EnterpriseDB, Citus Data, Greenplum, etc) along with the larger PostgreSQL consultancies which would probably raise their hand if they thought one player or another was becoming dominant in some way hostile to the others. All of this is outside observer speculation, but it's the way I read the tea leaves.
      - anarazel 9y ago
        >> Wasn't there in fact an agreement amongst the PostgreSQL contributors that they'd never all go and work for the same company? At least some of us have that understanding - and looking at where at least the committers work it's fairly well distributed. > Having said that, there do seem to be some larger concentrations of them in a few companies. I don't keep up too much with that either, but it seems like EnterpriseDB was in this camp (and logically so). There is some concentration, but if you look at the list of committers (smaller number, I don't have to look up affiliations), they're fairly well distributed across the the larger players (alphabetically 2ndQuadrant, Crunchy Data, EnterpriseDB) and various other orgs with some.
jeyoor 9y ago
In addition to the Postgres knowledge, this post also provided me with tremendous help in building a sane data architecture for RESTful web services in Haskell.
_asummers 9y ago
We solved this differently. We needed to maintain a two DB solution (two-state solution as some of my team has called it). For this, we took advantage of RethinkDB's changefeeds to deal with the foreign key constraints. We have some Elixir supervisors that link to it's direct dependencies. So e.g. a Comment can't exist without a Post, so the Comment changefeeds don't start until the Posts insert changefeed caught up with at least upserting the IDs. We then have a followup task that makes sure the data is also up to date. This has allowed us to keep our FKs, while allowing functionality to be moved over as we needed it to. As new_app became the writer, changefeed was removed, and the process continued. If one dies for whatever reason, it kills the dependent changefeed listener processess and the VM restarts the process at that point.
gilbetron 9y ago
After starting up a big data timeseries project at work for the past several years, and spending a big chunk of that looking into and testing various DBs, whenever I am asked, "What database I should use for X?" I tell them Postgres, unless you have an well-researched and proven reason not to. I picked Druid for our project, and am very happy with the result. However, for some of our smaller customers, Postgres would have been a much better choice. Only because most of our big, important customers have data needs starting at Petabytes am I happy we went with Druid. Well, that and a bunch of other reasons ;) Much of the "reasoning" I see for people choosing Elasticsearch or InfluxDB or MongoDB seems to come down to, "It showed up a lot on Hackernews".
- Chickenosaurus 9y ago
  I am currently working on a thesis paper evaluating persistence technologies regarding their fitness for a petabyte-scale sensor data analytics product. I am interested to learn more about your experience with Druid. I would be grateful if you contact me at 8nvyve+wj7zvh7q5e0@sharklasers.com (it's a throwaway email as I avoid posting my private email publicly). Thank you.
elvinyung 9y ago
I really wish that there was a column-oriented storage native to Postgres. My impression is that people are forced to abandon Postgres for analytical processing way too early, at relatively small scales.
- gdulli 9y ago
  There sort of was, but unfortunately Amazon bought it and renamed it to Redshift and now you have to rent it.
  - elvinyung 9y ago
    I thought Redshift was built completely from scratch, and only looks like Postgres at the wire protocol level? Also, it would be really nice if I could do both my transactions and my analytics in the same box. Then ETL is basically just maintaining a materialized view.
    - scapecast 9y ago
      Amazon built Redshift by using technology from Paraccel. Paraccel was built on Postgres. See a Quora answer I wrote: https://www.quora.com/Amazon-redshift-uses-Actians-ParaAccel-MPP-database-so-what-does-Amazon-redshift-team-work-on-Only-integrating-ParaAccel-in-amazon-ecosystem-Do-some-people-from-Redshift-team-work-on-ParaAccel-database-as-well https://www.quora.com/Amazon-redshift-uses-Actians-ParaAccel...
- tnndk 9y ago
  There is the cstore foreign data wrapper, https://github.com/citusdata/cstore_fdw https://github.com/citusdata/cstore_fdw, but it is still an extension. Hopefully it will go into mainline at some point.
- anarazel 9y ago
  FWIW, I think currently column vs. row-store is not in the critical path of making postgres more suitable analytical query processing. The CPU bottlenecks are just elsewhere - and we (various postgres devs) are working on them. The storage density parts of column stores can currently partially be achieved by using a filesystem that does compression - far from great, but not disastrous either.
sagefy 9y ago
Interesting timing... literally just just finished moving from RethinkDB to Posgres myself https://github.com/heiskr/sagefy https://github.com/heiskr/sagefy . When I was first building the project, I didn't totally know what schema I would need. I started on Postgres. But having to constantly do database migrations while I was developing was a pain. RethinkDB was great for development while I was figuring out what schema I needed. But now that the website is live https://sagefy.org https://sagefy.org , the schema started getting stable. I'm not using perfect third-normal form, but in many cases I have no query needs there so JSONB makes sense. JSONB columns can actually remove much of the need for NoSQL. The biggest gains from moving were: not having to do foreign key validations myself (yay!) and about 2/3 filesize reduction to the database. My database isn't large enough for performance to matter, but I'm sure it would eventually. If I were to do this again, I would probably start again with a NoSQL database (maybe Redis or ES, or just files even) until I figured out the schema and then move to Postgres before launching. I'm sure there's smarter people out there who can start with SQL and predict easily what the feature set is going to be be before they start, but I don't usually have that foresight. `ALTER TABLE ...` gets old really quickly. I'm keeping an eye on CockroachDB too... if they can really make something similar to Postgres but easily scales horizontally... that would be amazing.
weeksie 9y ago
Document databases are for data you know will be hierarchical and you know you won't have to do much cross referencing on. That's not as broadly useful as it might sound and then once requirements change you end up reimplementing a RDBMS in your NoSQL. I don't hate doc dbs, I just don't think they're as generally useful as they're made out to be. Relational is well understood. The modeling problem is well understood so you don't have to guess too much about how your data should be structured. By default I start projects with a rdbms and then carve out the portions that truly are hierarchy-only. That said, I'm starting to investigate graph databases more closely and what I like about them is what I like about relational: queryability. It's so easy to write a short query and extract your data. I like the model quite a bit too because graphs are a pain to shoehorn into a relational db. I'm still not entirely sold but I would love to find more good resources on graph dbs.
- brlewis 9y ago
  How much does WITH RECURSIVE help to reduce pain with graphs in PostgreSQL?
- philliphaydon 9y ago
  But data you store in a relational database is also hierachical... Order / OrderLine In a document db we store it as a single document because an order is the root aggregate and the order line cannot exist without an order. It relates to other objects in the database in the sense that it may relate back to a User... We hack together our "understood" objects to fit into a relational database.
schuyler2d 9y ago
Wow, we had to do the same thing recently. Rather than replace all the model queries across a complex codebase, we created a rethink-(rdbms=knexjs in node) adapter layer which gave us a nice 80/20 solution. https://github.com/MoveOnOrg/rethink-knex-adapter https://github.com/MoveOnOrg/rethink-knex-adapter
coolsunglasses 9y ago
I talked to Phil about this migration, I maintain two of the libraries mentioned in the post. I mentioned the Elasticsearch client (which I actually wrote, unlike the SQL library) in this comment: https://news.ycombinator.com/item?id=15241886 https://news.ycombinator.com/item?id=15241886 Maintaining each library has enhanced my appreciation and respect for how the Postgres people do their thing.

135 points by okket 9y ago

"Postgres is basically going to be around forever". My favourite quote from the article and a really great point. Even with RethinkDB going opensource there's only been one single release in the last year, and it was a bug fix release.

noncoml 9y ago
With RethinkDB and Basho going out of business, it has an interesting year for databases. I think we are seeing the dawn of the new databases golden era, and the world is converging to 3-4 databases, that is Postgres, Cassandra and Mongo and ElasticSearch.
- paxy 9y ago
  MySQL still has massive usage, and isn't going anywhere.
  - noncoml 9y ago
    Agreed, I meant other than Oracle, MySQL/MariaDB and MSSQL, which are the top 3 anyway.

thecopy 9y ago

I am beginning to see a trend on HN. Teams are moving away from new and young databases to old and "boring" databases as their need for stability and correctness increases.

pjmlp 9y ago
Which is why we grey beards just wait for the caravan to pass until the dust settles, then we get back to action and recover our dues.
dm3 9y ago
Would be interesting to hear how they arrived at the RethinkDB/Elasticsearch combination over Postgres at the start of the project. It doesn't seem they lost any features after the transition. Was something lacking in Postgres at the time of initial implementation?
- chris_st 9y ago
  However, they do say: > leaning heavily on Haskell in order to fill in some of the gaps quickly. So it looks like they had to do some work to cover some features from rethinkdb/elasticsearch.
  - fmap 9y ago
    The code in the post is just used to migrate from an untyped interface to a typed one. Unless I'm missing something, there seems to be no mention of any missing features in postgres.
    - Yeroc 9y ago
      They did mention missing JSON schema validation in Postgres.
      - billrobertson42 9y ago
        And also many mentions of no schema validation in Rethink, so that's probably not a gap.
deleted 9y ago
[deleted]
Thaxll 9y ago
hmm not really, it doesn't make any sense ( text search included ) to put everything into PG. PG doesn't even have a clustering solution out of Citus, how do you scale / HA postgres using the default setup without doing sharding yourself?
- X86BSD 9y ago
  What? There are over a dozen. See: https://wiki.postgresql.org/wiki/Clustering https://wiki.postgresql.org/wiki/Clustering Some commercial.
  - Thaxll 9y ago
    Those are third parties extensions, ES does clustering out of the box well. Most of the thing on your list don't have proper clustering solution built-in which means you have to support it yourself.
    - X86BSD 9y ago
      You said that PG had no clustering solutions, I showed you there were. Some of them may require more work than others but there ARE clustering options none the less for PG. It's inaccurate to say there are none.

fiokoden 9y ago

Postgres is always the answer.

qaq 9y ago
Well not always but for a wast majority of cases it's a very strong option.
virmundi 9y ago
No it's not. It's question dependent. "Would you like a burrito?" "Postgres". See? It doesn't work.
- jacquesc 9y ago
  Works for me. I'd probably lose weight if I started using that answer.
- sin7 9y ago
  Pos que cres? (What you think?) Seems like a legit answer to me.

yipopov 9y ago

I've had a prodigal son moment with Postgres myself. I found that even for many tasks that seem to favour NoSQL (time series, etc.) you get lot more bang for the buck in terms of performance for the same resource usage with Postgres.

firasd 9y ago

Interesting quote: "we decided to compute all statistics on demand. This was something we previously tried in RethinkDB, but the results were not good... When we tried implementing statistics as SQL queries in Postgres, we were amazed by the performance. We could implement complex statistics involving data from many tables." I think standard line "use right tool for the job" is still the ultimate answer. Data in most applications is relational, and you need to query it in different ways that weren't anticipated at the beginning, hence the longevity of SQL. That said, I too often see HN commentators say something like "this data was only 100 GB? Why didn't they just put it in Postgres?" which is not as clever as the writer may think. Try doing text search on a few million SQL rows, or generating product recommendations, or finding trending topics... Elasticsearch and other 'big data' tools will do it much quicker than SQL because its a different category of problem. It's not about the data size, it's about the type of processing required. (Edited my last line here a bit based on replies below.)

qaq 9y ago
We do exactly what you describe on about 80TB dataset stored across a number of PG instances. The 100GB comments are extremely clever because running a query against a dataset that fully fits in RAM will be blazingly fast. "Try doing text search on a few million SQL rows" we are doing it on billions of rows.
- probablybroken 9y ago
  I think some of this can be attributed to expectations; Many systems such as elastic are expected to run on ram, whereas people tend to expect relational systems to perform reasonably well on disk. I think we all want a magic black box that makes such problems disappear, and we always seem to be disappointed with the system in question when at some point it doesn't.
  - qaq 9y ago
    You are 100% right the perpetual search for "magic black box" is the cause of much pain on the bright side it's also a source of significant amount of high paying work to clean up the mess.

cyberferret 9y ago

> Rethink is no longer commercially maintained. Just wondering, seeing as am not a Postgress user - is Postgress commercially maintained? Or is it pure open source (like I believe RethinkDB is currently)?

detaro 9y ago
Postgres is Open Source, but multiple companies sell support, employ devs and/or provide distributions of it.
sbuttgereit 9y ago
There is no single company behind PostgreSQL, there's a foundation which manages development, but there are a number of well established businesses offering commercial grade support. Some of these companies employ some of the major contributors to PostgreSQL.
- rwmj 9y ago
  Wasn't there in fact an agreement amongst the PostgreSQL contributors that they'd never all go and work for the same company?
  - sbuttgereit 9y ago
    I'm not sure (others here, naturally, may be in the know). Having said that, there do seem to be some larger concentrations of them in a few companies. I don't keep up too much with that either, but it seems like EnterpriseDB was in this camp (and logically so). I do think there are enough companies now that develop PostgreSQL based products (EnterpriseDB, Citus Data, Greenplum, etc) along with the larger PostgreSQL consultancies which would probably raise their hand if they thought one player or another was becoming dominant in some way hostile to the others. All of this is outside observer speculation, but it's the way I read the tea leaves.
    - anarazel 9y ago
      >> Wasn't there in fact an agreement amongst the PostgreSQL contributors that they'd never all go and work for the same company? At least some of us have that understanding - and looking at where at least the committers work it's fairly well distributed. > Having said that, there do seem to be some larger concentrations of them in a few companies. I don't keep up too much with that either, but it seems like EnterpriseDB was in this camp (and logically so). There is some concentration, but if you look at the list of committers (smaller number, I don't have to look up affiliations), they're fairly well distributed across the the larger players (alphabetically 2ndQuadrant, Crunchy Data, EnterpriseDB) and various other orgs with some.

jeyoor 9y ago

In addition to the Postgres knowledge, this post also provided me with tremendous help in building a sane data architecture for RESTful web services in Haskell.

_asummers 9y ago

We solved this differently. We needed to maintain a two DB solution (two-state solution as some of my team has called it). For this, we took advantage of RethinkDB's changefeeds to deal with the foreign key constraints. We have some Elixir supervisors that link to it's direct dependencies. So e.g. a Comment can't exist without a Post, so the Comment changefeeds don't start until the Posts insert changefeed caught up with at least upserting the IDs. We then have a followup task that makes sure the data is also up to date. This has allowed us to keep our FKs, while allowing functionality to be moved over as we needed it to. As new_app became the writer, changefeed was removed, and the process continued. If one dies for whatever reason, it kills the dependent changefeed listener processess and the VM restarts the process at that point.

gilbetron 9y ago

After starting up a big data timeseries project at work for the past several years, and spending a big chunk of that looking into and testing various DBs, whenever I am asked, "What database I should use for X?" I tell them Postgres, unless you have an well-researched and proven reason not to. I picked Druid for our project, and am very happy with the result. However, for some of our smaller customers, Postgres would have been a much better choice. Only because most of our big, important customers have data needs starting at Petabytes am I happy we went with Druid. Well, that and a bunch of other reasons ;) Much of the "reasoning" I see for people choosing Elasticsearch or InfluxDB or MongoDB seems to come down to, "It showed up a lot on Hackernews".

Chickenosaurus 9y ago
I am currently working on a thesis paper evaluating persistence technologies regarding their fitness for a petabyte-scale sensor data analytics product. I am interested to learn more about your experience with Druid. I would be grateful if you contact me at 8nvyve+wj7zvh7q5e0@sharklasers.com (it's a throwaway email as I avoid posting my private email publicly). Thank you.

elvinyung 9y ago

I really wish that there was a column-oriented storage native to Postgres. My impression is that people are forced to abandon Postgres for analytical processing way too early, at relatively small scales.

gdulli 9y ago
There sort of was, but unfortunately Amazon bought it and renamed it to Redshift and now you have to rent it.
- elvinyung 9y ago
  I thought Redshift was built completely from scratch, and only looks like Postgres at the wire protocol level? Also, it would be really nice if I could do both my transactions and my analytics in the same box. Then ETL is basically just maintaining a materialized view.
  - scapecast 9y ago
    Amazon built Redshift by using technology from Paraccel. Paraccel was built on Postgres. See a Quora answer I wrote: https://www.quora.com/Amazon-redshift-uses-Actians-ParaAccel-MPP-database-so-what-does-Amazon-redshift-team-work-on-Only-integrating-ParaAccel-in-amazon-ecosystem-Do-some-people-from-Redshift-team-work-on-ParaAccel-database-as-well https://www.quora.com/Amazon-redshift-uses-Actians-ParaAccel...
tnndk 9y ago
There is the cstore foreign data wrapper, https://github.com/citusdata/cstore_fdw https://github.com/citusdata/cstore_fdw, but it is still an extension. Hopefully it will go into mainline at some point.
anarazel 9y ago
FWIW, I think currently column vs. row-store is not in the critical path of making postgres more suitable analytical query processing. The CPU bottlenecks are just elsewhere - and we (various postgres devs) are working on them. The storage density parts of column stores can currently partially be achieved by using a filesystem that does compression - far from great, but not disastrous either.

sagefy 9y ago

Interesting timing... literally just just finished moving from RethinkDB to Posgres myself https://github.com/heiskr/sagefy https://github.com/heiskr/sagefy . When I was first building the project, I didn't totally know what schema I would need. I started on Postgres. But having to constantly do database migrations while I was developing was a pain. RethinkDB was great for development while I was figuring out what schema I needed. But now that the website is live https://sagefy.org https://sagefy.org , the schema started getting stable. I'm not using perfect third-normal form, but in many cases I have no query needs there so JSONB makes sense. JSONB columns can actually remove much of the need for NoSQL. The biggest gains from moving were: not having to do foreign key validations myself (yay!) and about 2/3 filesize reduction to the database. My database isn't large enough for performance to matter, but I'm sure it would eventually. If I were to do this again, I would probably start again with a NoSQL database (maybe Redis or ES, or just files even) until I figured out the schema and then move to Postgres before launching. I'm sure there's smarter people out there who can start with SQL and predict easily what the feature set is going to be be before they start, but I don't usually have that foresight. `ALTER TABLE ...` gets old really quickly. I'm keeping an eye on CockroachDB too... if they can really make something similar to Postgres but easily scales horizontally... that would be amazing.

weeksie 9y ago

Document databases are for data you know will be hierarchical and you know you won't have to do much cross referencing on. That's not as broadly useful as it might sound and then once requirements change you end up reimplementing a RDBMS in your NoSQL. I don't hate doc dbs, I just don't think they're as generally useful as they're made out to be. Relational is well understood. The modeling problem is well understood so you don't have to guess too much about how your data should be structured. By default I start projects with a rdbms and then carve out the portions that truly are hierarchy-only. That said, I'm starting to investigate graph databases more closely and what I like about them is what I like about relational: queryability. It's so easy to write a short query and extract your data. I like the model quite a bit too because graphs are a pain to shoehorn into a relational db. I'm still not entirely sold but I would love to find more good resources on graph dbs.

brlewis 9y ago
How much does WITH RECURSIVE help to reduce pain with graphs in PostgreSQL?
philliphaydon 9y ago
But data you store in a relational database is also hierachical... Order / OrderLine In a document db we store it as a single document because an order is the root aggregate and the order line cannot exist without an order. It relates to other objects in the database in the sense that it may relate back to a User... We hack together our "understood" objects to fit into a relational database.

schuyler2d 9y ago

Wow, we had to do the same thing recently. Rather than replace all the model queries across a complex codebase, we created a rethink-(rdbms=knexjs in node) adapter layer which gave us a nice 80/20 solution. https://github.com/MoveOnOrg/rethink-knex-adapter https://github.com/MoveOnOrg/rethink-knex-adapter

coolsunglasses 9y ago

I talked to Phil about this migration, I maintain two of the libraries mentioned in the post. I mentioned the Elasticsearch client (which I actually wrote, unlike the SQL library) in this comment: https://news.ycombinator.com/item?id=15241886 https://news.ycombinator.com/item?id=15241886 Maintaining each library has enhanced my appreciation and respect for how the Postgres people do their thing.