I'm the dir. of eng. for the team building flux. Before that, I built a transactional SQL system (during peak NoSQL hype). I like SQL. After a year+ of watchin

I'm the dir. of eng. for the team building flux. Before that, I built a transactional SQL system (during peak NoSQL hype). I like SQL. After a year+ of watching people use InfluxQL and thinking about the types of user experiences that timeseries specific platforms can offer - I'm eager to see flux enter the world. People like exploratory and notebook like environments. Building a language that integrates with those workflows and even supports a REPL for writing queries is a nice fit to this space. InfluxDB chooses a non-relational data model. Timeseries queries almost all filter on terms, partition, window, group - and then apply a sequence of functions to those groups. Most queries end up using SQL analytic functions that many users aren't experienced using... while mapping a only vaguely-relational (and very non-normalized) data model to boot. The timeseries space is visual - visual tooling really matters. SQL isn't an easy fit there, either. It is hard to write SQL incrementally or to interpret just part of a SQL query to show intermediate results. Additionally, users expect a large set of non-standard SQL functions to be builtin. There are competing systems betting explicitly on SQL and others choosing a functional approach, a strong competition of ideas and practices which should be a win for end-users. (And to correct the above comment, flux expresses select, project, and join operators.)