If you're only using Ecto for schema modules, changeset functions, inserts, and updates, you're missing out on some great features.
Without a database: Ecto.Types can be used to convert stringly-typed data from any source to native Elixir; Ecto.Changeset can be used as a convenient way to accumulate errors when going between layers with richer support for nested and translatable errors than error tuples with a String or a list of Strings.
Ecto migrations can represent primary keys that aren't integers and more closely reflect unique identifiers in your domain; join tables that use composite primary keys that represent what’s unique about the join instead of an arbitrary id column; accurately represent the difference between time keeping in the database and in your Ecto schemas using different timestamp configs.
The full power of Postgres is available through Ecto constraints: unique constraints can be tuned to specific conditions; exclusion constraints make ranges and scheduling easy; and check constraints are even more general and allow modeling complete validation logic in the database. Constraints ensure that different code paths can't corrupt your data and violate business rules. Leaning on the database constraints is crucial when doing bulk operations in concurrent ETL pipelines, but Luke will show how you don't need to abandon changeset and validations just because insert_all doesn't support inserting changesets.
Luke Imhoff has been writing Elixir since June 2014 and started writing IntelliJ Elixir in July 2014 after he couldn't find pre-existing support for Elixir for JetBrains IDEs he loved like Rubymine. While developing the plugin, he's found bugs in the native Elixir lexer and parser. He has 3 hex packages for JSONAPI: Alembic (validate format of JSONAPI), Calcinator (transport neutral JSONAPI, so you can use them for APIs and RPCs), and Retort (JSONAPI over JSONRPC over RabbitMQ for RPC). He hosts the Austin Elixir meetup on the 3rd Monday of each month.