My unease is partly to do with borders and technological alliances. Ecto offers several things, but in defining its own server-side query language it redraws the boundary between a web technology and a database one, rather than simply mediating between the two. I'm not sure that that is sustainable or a good use of energy. My experience of databases is that they are often a bit of a mess, for whatever reason, so you need all the tools you can get to get the data into into the shape you want.
It can also be that much data does not arrive via a UI, so you end up managing code in different places with different syntaxes. Report writers, such as Crystal Reports, are often going to rely on stored procedures. Who's in charge when multiple web apps access the same databases?
Again, is it a good use case for MongoDB to treat it as a relational database? What of the graph databases that are becoming more popular? Can they all be treated as relational?
I suspect that we are going to end up with drivers for each database. It would be a pity to lose Ecto because it has a lot that is very handy. However, it seems (at this still early point in my education) far from being a no-brainer to keep it. A preferred model that comes to mind is the Elm one where you define client side data structures and provide decoders for a stream of json data to populate them.
The coupling issue that DianaOlympos mentions is a real one. But, I still want my database back, dude.
Fortunately my immediate needs are simple enough that I can comfortably use Ecto for my next project, which I am looking forward to, and will hopefully understand more about at the end. For the job I have just finished, though, it's the guys from the last century that are in charge, and Ecto, in its current form, would be a pretty tough sell.