So what is the problem with sqlite?

I think most choose PostgreSQL or MariaDB for production and it is easier to run the same database both in production and in development so you can make use of the DB’s features (like PostgreSQL’s jsonb field).

Thanks for your answer, yes I know mysql and postgresql.
I just wanted to know if there are some known problems with sqlite - I know it is not recommended for production, but still there are many applications out there using sqlite for production (e.g. on android phones).
I guess that concurrency issues may kill sqlite usage?
Or is there anything inherently broken with elixir and sqlite?
Thanks again!

I am interested in this topic as well, and comments from people with experiences. For example, this guy sticks sqlite on top of Erlang/Genserver.

So, I think it should work and maybe a Riak alternative.

They have a very unique use case, so it’s hard to generalize from it. To be a viable option it would need a lot more users and contributors (ActorDB not SQLite).

Quite simply, you should use the same database in development and testing that you use in production.

I think that for embedded platforms such as phones, Raspberry Pi’s, other microcontrollers etc. it is probably more worthwhile to use ETS (Erlang Term Storage), as it is built-in in the language, and therefore a lot faster to communicate with it. ETS was also built from the get-go with concurrency in mind, and can also be used to create RAM-based memory stores, which makes it a lot faster (of course, at the cost of using more RAM)

On the other hand, ETS takes some getting used to, because it does not use a conventional Structured Query Language syntax, but rather a pattern-match esque syntax.

And while I do not know how good (or bad) SQLite will work with concurrent applications, I do know that it really helps to have the same database locally as on a production server. In the past, we’ve had rounding troubles with our decimals when going to the test and production environments, because SQLite doesn’t care about the precision of DECIMALs, while MySQL and PostgreSQL will. And the same is true for STRING vs TEXT, which is the same in SQLite, which means that MySQL might throw errors in production when suddenly things don’t fit in something you thought could be a string.

Becase SQLite isn’t trendy enough.
I use it everyday for most of my applications because the deployment & configuration cost is null and the performance impact isn’t visible, compared to PostgreSQL

Largely that ETS/DETS/Mnesia are already built in without requiring an external dependency. I can’t think of a use case for SQLite that isn’t addressed by those already (aside from existing familiarity).

This is not true

We don’t pick features based on their trendiness. If you don’t believe me, see our choice of brunch instead of webpack . Postgres is the default db adapter for new apps simply because in my experience it’s the defacto choice for prod environments, both for my client’s apps, and what I use personally, along with my peers. That said, the Ecto adapter ecosystem has first class support for other adapters, such as mysql, mongoldb, and sqlite that can be used with a single flag to the generator. The issue on the sqlite end is the ecto sqlite adapter has not yet been updated to Ecto 2.0, and the phoenix-core team can’t be responsible to maintain every db adapter that exists. I encourage those in the community who want the best sqlite experience to become contributors on that project so that you can run mix phoenix.new app --database sqlite and be up and running as you wish.

Some support is on offer from the Ecto team for anyone updating a driver: Support DBConnection · Issue #1215 · elixir-ecto/ecto · GitHub