What would you like to see from a native Elixir database?

Ideally FoundationDB + SQL compatibility. Sorry for low-effort response but lately I’ve been fangirling over FoundationDB way too much.

I’ll turn this question on its head: what sort of features, functionality, and so on are you envisioning you can ONLY get with an Elixir database?

As you should!

Indeed, FDB is essentially the perfect architectural donor. It checks off almost everything on my list (though I do have a few more things I want which FDB doesn’t support). But of course FDB cannot be embedded in Elixir!

As for SQL, I think it’s a mistake. One very important thing I left off the list is incrementalization, i.e. live query support. SQL is made up of several decades of bloat and functionality which is probably useful for business processing but not useful for application building (my primary interest). Incrementalizing all of that functionality is essentially impossible (people keep trying, though).

Honestly I’d rather just bite the bullet and throw it away. It’s not like SQL was ever even good to begin with, it survives because it’s the standard (and yet every implementation is nonstandard, funny how that works!).

I don’t think there is any functionality which you could only get with an Elixir database. Even a database written in C could technically satisfy the “embedded” criterion if you were ambitious enough.

I will, though, gladly accept responses that reinterpret the question as “what features, functionality, and so on would you like to see from a new database which is by total and complete coincidence written in Elixir”

What is the issue with SQL, it’s a language and it’s implementation dependent, so you could use it for anything that works on sets which is most data, relational or not.

There are so many SQLish languages out there, datadog, grafana etc that would have benefited from being a subset of SQL with implementation specific operators.

Really opening pandora’s box here, you could write a book on what’s wrong with SQL (and I bet there are several). Instead of derailing the thread into oblivion (I’m fully aware it’s my own doing) I’ll instead link this article which I enjoyed and need to read again. But there are so many more reasons.

Which is kind-of the point I was making. SQL’s best selling point is that it’s a standard (it’s bad at pretty much everything else) except it’s also not even good at that. You can’t even trivially port an app between MySQL and Postgres!

I am fully aware you are the author of the SQL library btw, which I think is really cool! But I will note that by adding composability to SQL you have, in fact, also managed to create something which is not SQL!

I don’t see how composability breaks anything, it’s still SQL, although with an advance engine that helps you write SQL that fits you.

To me, when people dis SQL, then it comes from a misunderstanding of what it is, regardless of the standard, most database are non standard, and there lies my point. SQL is whatever the query planner decide. Because the standard is implementation specific, which is, for me, a superpower.

Changing database is not a solid argument, because you rarely do it, and if you need to, then you can afford it too.

I am not trying to suggest that it “breaks” anything. I think your library is really cool, I’ve never seen anything quite like it before. It’s like a hybrid of an ORM DSL and actual SQL syntax, which makes up for one of the biggest shortcomings of SQL (hard to compose).

But the reason you have to make up for shortcomings of SQL with DSLs (or very clever macro strings that look like SQL but are not, actually) is that SQL itself is, uh, bad.

Well no, the execution of the query plan is what the query planner decides. SQL is a language. It does actually exist, like, as a language. There were better languages before it (QUEL), but it won because, you know, IBM.

I’m sure it comes as no surprise that I agree with your list.

I would be eager to use, and contribute to, a BEAM native DB with a low level API compatible with FDB’s core feature set (ordered keyset, get range, clear range, transactions, mvcc). A high level relational API is where many people would live, but the direct storage engine access is so powerful.

The FDB team never got the chance to implement all the Data Layers on top of their storage engine because of the acquisition. It would be exciting to have an ecosystem where those ideas could carry on.

Here’s a few things I would add to a wishlist

• Stellar documentation
• Public roadmap, including list of what features are considered “experimental” and whether or not there is an expected path/timeline toward production safety
• No query planner, or a very limited one. Permissive planners have caused me a lot of headaches.

Exactly , it’s a language, but how the query planner decides to interpret and execute that, is sole on the query planner. And that is exactly why you would not need any other languages regardless of your data is
relational or not.

To take it a step further, there is nothing stopping us from querying mnesia, ets or dets with SQL. In fact this has already been done with Ecto.Query.