Is an SQL interface still planned? Is there a rough timeline (Q4 2020, etc) when it may become available?
I thought I read that an SQL interface is planned, but I can’t find it anymore. I won’t hold anyone to the date.
I like Fauna’s features (zero maintenance, HA, scaleable, versioning, speed, auth, HTTP connections for serverless, etc), but after writing a multiUpsert (with lots of help! thank you!) and a multiDelete query, I think FQL is too low level for my rapid development style. I find it verbose & harder for me to use than SQL, Mongo, etc. I can see how it could be powerful for some people, but just maybe not a good fit for my use.
A long while back, there was an announcement when we planned to work on the feature. That announcement was probably released a bit too soon since right after our roadmap surveys have suggested that there was a low interest in SQL and hence it has been deprioritized.
FQL does require you to get used to it, typically at a certain moment it ‘clicks’ and from that point on people find it easier than SQL for complex statements (yet more verbose). Of course, that’s different for everyone and if you have an SQL background, FQL will look exotic. Your points on the low-level aspect are taken seriously, we are hoping to introduce a higher-level version of FQL where you can still opt-in to get access to the lower-level constructs but you don’t have to start with them.
Might be worth mentioning that there is selection bias in this group. Early Fauna users are those for whom FQL/GraphQL probably already fits their needs, otherwise they wouldn’t be around to take part in the survey.
Thanks for mentioning Biota in the other thread. Will give it a try.
In case the desire for SQL is taken too critically, that’s not my intention. I see Fauna as excellent for dev ops productivity, but programmer productivity, FQL isn’t…a good fit for me. Hopefully a wrapper like Biota will improve that.
we are hoping to introduce a higher-level version of FQL where you can still opt-in to get access to the lower-level constructs but you don’t have to start with them
That would be fantastic, or even helping mature Biota. Ultimately, my perspective as a developer, is that which language I use isn’t important, as long as my productivity stays the same or improves compared to tools used previously.
Thats a shame. I think quite a few SQL folks would take a hard look at FaunaDB given all of its benefits if the learning curve next to none!
With SQL, you create the tables and you can query the data any way you like; obviously you’d create indexes to help speed up searches, but it isn’t necessary to get going. This is where with SQL you can get going quickly. I’m finding with FQL that you have to really think about the queries you need to do on data (create indexes etc) which means you have to either front load your thinking or break your train of thought when coding to come back to FQL.
The GraphQL interface, while interesting and helpful in basic cases, by default does not do all the things I would need it to do. As such for anything reasonably complicated FQL becomes a must, even when using the GraphQL interface.
I’ll take a look at this series to see if this helps with respect to learning.
I’m just spitballing, but even something that translates SQL into FQL (including indexes needed etc), could even be helpful so you can think in SQL and get a better idea of what FQL it translates to. Everything is easier said than done though.
I agree, but I do think the fauns who took action based on the roadmap were aware of that when they made this decision (fyi, I didn’t work at FaunaDB yet back then)
Absolutely, and we do deeply appreciate the feedback. But it’s all about picking battles . Creating a database is a lot of work.
This is by design and even if we would support SQL, I suspect this will not change and those indexes would be generated for you (as happens in our GraphQL). It’s indeed easy to get going but it’s a great idea to make sure you have indexes before you query as they are often forgotten later on. In essence, FaunaDB makes sure you don’t shoot yourself in the foot in the long run and tbh I’ve seen it happen quite often in my consultancy years (and the programmers that made these errors were highly competent). In a pay-as-you-go/massive scalable database that can be very painful. Imagine your data grows really quickly and have 100 million documents and you select a few of them. Wouldn’t it be a bit strange if FaunaDB decides: “You don’t have an index, no problem… I’ll charge you 100 million read ops instead of one index lookup read op”?.
That doesn’t mean SQL is not possible but I do personally think that the idea of creating indexes beforehand is a very good idea and there were times I’ve spent debugging apps in my former developer life that I wished SQL was designed like that . That said, we can in the future probably help out/give pointers, e.g. you could just write your query and get a prompt: “this query does not have a suitable index, do you want us to create one?” wherever possible.
Point taken though. FQL should be easier to get into, and we are working hard on that!
You’re absolutely right in that no one would want that “100 million read ops” bill and I’ve seen the same happen in the past. But if we can find a way for FaunaDB to create indexes we need ‘automagically’, that would be ideal.
Yes something like the “make new index prompt” would definitely go a long way. At the end of the day every language we use compiles/transpiles or is interpreted as a lower level language. Lots of magic happens underneath the hood. FQL, as I understand it is the foundation on which other higher level languages can be built.