For sure, Ecto.Changeset "client-side" validations are a powerful tool even without any Ecto.Repo to insert the validated changeset into. You can just take the

For sure, Ecto.Changeset "client-side" validations are a powerful tool even without any Ecto.Repo to insert the validated changeset into. You can just take the validated Ecto.Changeset, and "bake it down" to either the new/modified data, or the delta, and use that. And you get proper per-DDD-use-case type-casting "for free", through Ecto.Changeset.cast invoking Ecto.Type.cast on all your schema fields. Though! I would say that you might just as well be making a mistake by not at least considering the question, when you reach for "raw" Ecto.Changeset validation, of whether whatever subsystem this is that has all these database-like needs that you're plumbing your way into, is just a Greenspunning of a database — something you could potentially rip out and replace with a database, and in so doing, end up with an easier-to-understand, easier-to-maintain system. (It's "easier-to-understand" not in the sense that your system is now less complex; but rather in that the complexity is now constrained by a formal abstraction — one that allows reasoning about the behavior of that component on a higher level. It's the same reason you'd turn a generic server "with state", into a finite-state machine; or turn a generic recursive-descent parser into a PEG grammar.) The Erlang runtime is nice, in that it has in-memory database-like features (e.g. ETS), that let you get pretty far in writing internal state-management logic, without using any kind of database. But when you find yourself writing code that relies on 1. taking complex user-submitted data, 2. validating it and casting it into domain types, 3. inserting it record-wise into an ETS table, 4. and then manually indexing that table across multiple fields... maybe it's time for a database! (It doesn't have to be a big database. Or even one that involves any external dependencies. There's an Mnesia adapter for Ecto, which is a combination I've always found fascinating — especially in the context of a single-node, memory-only Mnesia setup. It's an ORM over transactionally-joined ETS tables! But of course, if you have control over your deploy-time environment and so can suffer a few native deps, then SQLite works great as your "internal database" too.)