I wrote about a fair amount of unexpected behavior with Sails/Waterline. Some of these have since been fixed, some of them (Waterline defaults to dropping tables unless you have NODE_ENV=production in an env var) are deliberate decisions and hence not "fixable". https://kev.inburke.com/kevin/dont-use-sails-or-waterline/
There's a fair amount of other stuff I would hope to change and that we've just ripped out of our fork.
- If count() isn't implemented in an adapter Waterline will fetch the entire table into memory to count the number of rows.
- Sails by default creates a route for every function in a controller, which makes it easy for an attacker to bypass policies
- blueprints routinely 500 server error based on user input
- https://github.com/balderdashy/waterline/issues/1248
- All SELECT queries on text fields call LOWER() before matching, so all of your indexes also have to match this
- There's a batch insert interface but N connections are established to insert N records... if one of the inserts fails, the behavior of the other inserts is not guaranteed
After the ugly discussion at the OP's link we decided to fork Sails and Waterline and rip out all of the stuff we don't need. I wrote about that here: https://kev.inburke.com/kevin/safely-moving-a-large-shrinkwr...