Try actually using Mongo in production for a while, then see how much you love it 
5 Likes
Your statement brings up a good question though:. Is there some reason why there isn’t an AP relational database?
I my particular case I’m interested in Graph DBs, specifically Graph, that happens to have an Elixir driver being developed.
But you may think the other way around: officially supported Elixir is locked in “old” SQL databases, PostgreSQL, MySQL and MSSQL
I think that this could be a big reason also in why it doesn’t get the traction we all expect. For developers like me, maybe for the one’s that came from Javascript Web Frameworks that could be a no go.
By “Relations” I mean complex relations between data, a few degrees deep, not just 1sf or 2nd level, which makes it hard for SQL under heave load. And then, the DBs officially supported are not as simple as scale as Elixir systems.
And, the fact that you may need to change your data models often as you cannot predict a lot of new unpredictable circumstances make “Relational” not the best for some scenarios.
Even if you think SQL covers 75% of all scenarios, you still have 25% that are not covered.
And those will never run Elixir without an official driver.
So in my view Elixir is not being used by some people the really enjoy it and use it at a personal level due to being locked to “old” SQL Databases.
In my personal case, I love it and I’m using it for simple systems IN SPITE OF having to use an SQL Database (I hate joins and all that thinking but use a lot of Embedded schemas to avoid it thanks to the good ECTO).
When I say simple I mean simple for the user (in this case the developer). And to build simplicity on the outside you need to “hide” extra complexity on the inside.
We look at Google and we see the simpler web-page that we can create (from an user perspective): a simple text field to insert what we want to look for. We all know what’s behind that…
So, I agree with you that Elixir is fantastic because it allow us very simple ways to handle all the complexity of Erlang.
And one of the reasons to create it was exactly that Erlang was almost perfect for the distributed future except that it was too complex, from the eyes of the developers coming from Ruby for example, to learn and use it.
My argument is the same with Relational DBs and SQL.
Anyway, I’m saying that now I don’t have a choice: I need to use SQL and Relational DBs if I want to use Elixir reliably in production. All other main languages have choices for that.
I think having options specially when it’s about the most important thing (maybe) in your system should be considered.
Agree with it or not, I think this may be one of the biggest issues prevent a larger adoption of Elixir as of now.
Except for static types. 
2 Likes
A great book that discusses a lot of important, relevant concepts in a practical clear way is Designing Data-Intensive Application.
My two cents: I strongly disagree that graph and document DBs “are the future”. They are a part of the future (along with any RDBMS) depending on the type of problem you are trying to solve, the requirements you have on your data (consistency, reliability, etc.) and the time constraints you are facing.
10 Likes
There are no officially supported databases in Elixir, all database clients are community projects in Elixir and none are part of the core language.
For graph databases I’ve used Neo4J, OrientDB and Postgresql with Elixir without any problems. Are those enough for your needs?
4 Likes
Yes, you cannot resign from C. Otherwise you can use /dev/urandom as your DB. Only thing that can be AP are CRDT-based datastores, and these cannot follow ACID much.
I need to do so only at the beginning of the development. After that changes are rare, and if needed, then I would say that RDBMs made some of the changes easier than harder.
But that is completely different from the statement at the beginning. Having drivers for other DBs is completely orthogonal to the fact that in 90% of cases SQL is best choice for the application.
That makes no sense, nothing, absolutely nothing lock you to “old” SQL databases. There are drivers for other DBs as well. So I do not get your point there.
Data normalisation is good thing, and joins are great - when used properly.
Erlang is much simpler than Elixir. You meant it was “unpleasant” for the rubyists.
That, again, completely different statement from what you stated at the beginning. Yes SQL is complex sometimes, but Ecto is exactly what you mean - it makes it much simpler. When you need to work with relational algebra, then SQL is currently “the language”. Ecto is trying to make it easier by changing syntax a little to be more like QUEL, but other than that, there is not much that is possible to change.
No you do not. You use Elixir with RDBMs because you do not want to maintain the driver and you want someone to do that for you. That not gonna happen, because if someone do not use DB of your choice then why the hell they would have any interest in maintaining such driver? There are drivers for most popular DBs out there, just look out on Hex.pm.
4 Likes
Yes, true, but if you want to use Ecto (which brings specific benefits such as Changesets,…, and being DB “almost” agnostic allowing you to change persistence layer latter) then you can read on Ecto’s documentation:
“The supported databases and their adapters are…”
That is very important for me.
Which you can use independently from the ecto_sql.
Which I am yet to spot in real-world. I have seen DB being replaced by new one using the same wire protocol (Google, TiDB, CockroachDB), but I am yet to see a big application that changes their DB without a rewrite.
Ecto, especially Ecto.Query is very SQL-centric. However if change sets is all you need, then you can handle that without any problems with any driver.
1 Like
Exactly. My view is from someone who is not yet very proficient in coding, is starting to code or coming from Javascript world. My view is also from someone who is highly proficient but knows the future problems of maintaining a 100% updated, compliant and reliable driver outside of a core team that also handles the core ecosystem (meaning, José Valim is very active in all key parts of the ecosystem, even now with the authentication part).
I agree with a lot of what you say, but at the same time think you miss my point: I think Elixir ecosystem would unlock the doors to much more developers by "officially " supporting another option for DBs rather than just traditional Relational DBs.
I have my personal preferences, you have yours, others will have different ones. I understand that we cannot have to many “official” options, but I believe this is one of the “details” that keeps preventing Elixir to have the adoption rate that it deserves.
Looking into Ecto documentation and only see traditional Relational DBs being mentioned in there…I remember that there was a time when we had MongoDb mentioned in there. And it was because of that, by then, that I decided to really use it.
The truth is that I still use it, even without MongoDB, as I later discover that MongoDB was probably not the best option, but it was looking into that possibility when I was assessing the Ecosystem that made my tried and start using it.
So, even if it would be only marketing, or the price to pay for larger adoption, I think we should have “officially” supported options.
The larger the user base the more libraries, blogs, support, recruitment base,…you have.
I would love to see the ecosystem grow at a faster pace.
And yes, I’m being selfish but I think it’s in a good way. 
The same applies to Jose or anyone from the core. They have exactly the same amount of time as you. Adding more libraries to maintain mean that they will need to do some sacrifices. I highly doubt that they want to sacrifice things for maintaining code that they do not use.
Most DBs use very simple protocols, it can be very good learning project.
What is your meaning of “officially”? Because it supports a lot of them:
- Redis
- MongoDB
- DGraph
- CouchDB
- Cassandra
- ArangoDB
- RethinkDB
- Riak
- Utilities for built-in Mnesia
- RocksDB
- LevelDB
- MemcacheDB
Because someone was maintaining the implementation. IIRC @michalmuskala was part of it. Now there is no-one who want to work on that. If you want, it can be You. I think you will find guidance and help with many people here, but no-one will do the job for you.
<sarcasm>It never is</sarcasm>
But why? Do we need such marketing? Do we need larger adoption that much? I would say - nah.
I on the other hand prefer to have slower growth, but with better quality of code. JS/Node/NPM community showed us what will happen when we sacrifice quality for the growth. Do not make that mistake again.
But JS do not have any “official drivers” for any DB (unless provided by the DB authors, then we can call it “official” for some meanings of that word).
5 Likes
I didn’t use Ecto for any of these projects and had no problems at all
3 Likes
I’d like to point out that although relational databases have proven their strength in some types of applications (e.g. transaction banking apps where complex relationships (in particular hierarchical) are not used).
However, it is true that some RDBMS limits are clear now since at least 10 years (mainly hierarchies are a pain, as well as (often related to that) complex queries can get pages and pages long and quite unreadable / unmaintainable).
Strangely RDBMS seem to remain quite dominant (a lot of specialized consultants are around and books and training of course … this slows down investment in new technology). However, very performing alternatives exist for many years.
I invite you to have a look at neo4j (graph database). You’ll discover that it is more relational than RDBMS 
because the relation itself becomes a first class citizen (having it’s own properties). Also the query language is such a pleasure compared to SQL (much more compact and closer to the natural intent of the query).
My intention is certainly not to criticize gratuitously all the beautiful work done for Elixir.
I also have no intention to hurt anyone’s feelings in this forum.
It is with a lot of respect for all of you, I write this chat !
I’m sure that in many cases Ecto helps the developer out very well (I’m new to Elxir at this stage, but I guess it must resemble ActiveRecord from Ruby?).
However for many use cases, graph databases are definitely the right choice.
Having it as a first class citizen in Elixir (just as an alternative next to RDBMS, not necessarily replacing it) would leave the freedom up to the developer to choose the option that fits his use case best.
So it’s not about something being “old”. I know theories of decades ago that still hold their value as of today. Most wine only gets better with age 
.
But in this case it’s good to acknowledge that alternatives exist.
It’d perhaps be nice to “open” up Elixir to them?
I will attempt to use neo4j with Elixir and I hope it won’t be too much of a pain.
When I will have done so, I’ll share my experience.
Enjoy the weekend! Stay safe.
Marc
2 Likes
Happy to read about your positive experience in combining Neo4J and Elixir.
It is my intention too. This is reassuring to read. Thanks.
There are CTE’s for that, and with tooling like Ecto or jOOQ it became more bearable. Also there are (were) other languages to query relational DBs, for example mentioned earlier QUEL or D4.
You seem to misunderstand what “relational” mean in RDBMs. JOINs aren’t “relations” in RDBMs, “relation” in sense of DBs is the different name for table.
Yes, except nn - see above.
Maybe, it depends, but what do would you say about having similar facilities in SQL standard?
Also important think - as I said before - SQL isn’t only language used in relational DBs.
Quite far from that. It is more like jOOQ. It is more akin to dry-rb from Ruby world.
I would say otherwise. It is pretty straightforward to migrate from SQL to graph when needed, other way around is much harder. Additionally you can simulate graph DB pretty effectively with SQL. Also as I said earlier, SQL standard is working on adopting some graph-like features.
No one says otherwise, and there exists enormous amount of drivers for different DBs already. Just not all of them are supported by Ecto. Using Neo4j example - it even mention them in official documentation.
EDIT: There is even Ecto adapter for Neo4j.
3 Likes
I can see the appeal, but at least for the applications I‘m creating there are hardly cases where the need for a graph db is greater than the need for a rdbms. And using multiple databases brings quite a lot of difficulties, which easily outweigh gains one would get from a graph database. In many other programming spaces mixing multiple technologies is far easier, but for databases (and transactions) this is not as simple.
2 Likes
Wow, you are a strong believer of RDBMS, more than just in love, it seems 
.
But I learned a few interesting things from your reply, most importantly that Ecto would support Neo4j, great! Very interesting.
Also your comment on Ecto being different from ActiveRecord is motivating me to take a close look at that.
I understand that you believe RDBMS should cope with its weaknesses by adding some graph features to it. Personally I prefer pure solutions rather than an attempt to have a Swiss knife. It is my impression (I don’t say it’s a fact, I need sufficient experience first before confirming it firmly) that graph databases encompass the relational approach: it offers RDBMS and more, with more flexibility and better performance. Everything I read and webinars I followed, seem to confirm this. In RDBMS I have like 30 years of experience, I have been teaching about the subject both at university and in private companies and I worked on many projects involving RDBMS in different roles fron technical to methodological). So I pretty well know the limitations. Despite all nostalgy I can be very objective about that.
Thanks a lot for your valuable feedback.
Thanks for your reply.
Do you mean difficult for the community to maintain Phoenix with different “native” db-options or for a developer mixing those different db-technologies?
The latter I personally prefer to avoid. I’m going to examine Neo4j as my future choice for any project I want to pursue. I’m not sure it has a limitation for which I’d need RDBMS. That’s what I want to find out. If not, I’ll stick to RDBMS and try to find some addons to compensate for its limitations. But I hope I will not need to.
1 Like
