Would you recommend this product?
No reviews yet
Huge fan of Mode Analytics, excited to see them roll out support for Python notebooks. I've always enjoyed using Jupyter / iPython notebooks locally but have found it a pain to set up a standalone server for sharing and collaboration. Poking around at the Mode Python Notebook, the entire process fits in flawlessly with their existing SQL editor + report builder -> they instantly expose the underlying data into the Python notebook. Also, all the popular data analytics libraries are already supported (pandas, matplotlib + seaborn,beautiful soup, scikit-learn, etc). Really stoked for this as a Mode customer! @dereksteer How long has the team been working on this feature? Will there be support for additional languages over time (R or Julia)? Also I heard some rumors about the new pricing model, are you free to discuss?
Upvote (13)Share
Thanks @liveink! I'm Benn, another one of Mode's cofounders - we're excited to launch it! As an analyst myself, I've wanted this combination of SQL + Python ever since I learned SQL, so this is a feature we've been thinking since the early days at Mode. It was always a bit of a dream until a couple engineers built a prototype at our first hackday last fall. We all got really excited about seeing it in action - even a smoke and mirrors version - and feeling how much it could change the way we worked in Mode. We began doing some research, and kicked off the work in earnest this winter. Regarding R and other languages, we're always thinking about how to make Mode better for analysts and data scientists. Python made a lot of sense to build first for a number of reasons, but if there are folks out there who like the combination of SQL and Python but are avid R users (few things seem to stir data scientists' emotions like debating which of the two is better…), we'd love to hear from them. And yup, we also launched new, more flexible pricing options today! Anyone can now sign up to use Mode, including Python Notebooks, for $19 a month. We believe that analytics tools shouldn't be affordable to only those with analyst in their job title. One trend we’ve seen among a lot of our customers is that people you wouldn't necessarily expect to be using SQL - PMs, QA engineers, operations teams, content marketers, and others - are creating and sharing reports in Mode. We wanted to make sure Mode is accessible to anyone who wants to be analyze data, whether they're a tenured data scientist, someone who works with data part-time, or just looking to learn.
Upvote (14)Share
Since Day 1 of becoming a Mode Analytics customer, we've been extremely impressed with them. They understand, from an analyst point of view, the difficulty of answering a business question using data. Mode Analytics platform was already extremely useful with it's SQL editor and scheduling functionality. Adding Python Notebooks is going to be a game changer. Our team at @fileright used Jupyter Notebooks separately until now. With the power of SQL and Python together in one place, answering difficult statistical questions has now become so much easier. Thanks, @ModeAnalytics!
Upvote (11)Share
I'm a huge fan of Mode and have used it extensively for our work in SQL. The past few weeks we've been using the beta for the Python notebooks and it really takes Mode to the next level. There's no other good tool out there to share and collaborate on live iPython notebooks. We've built really sophisticated pipelines for our clients using the new Mode reports. Can't wait to see where this goes next. And the new pricing makes it a no brainer for our clients to use.
Thanks @dereksteer and team, we were about to move away from Mode after our trial, because the pricing layers were to expensive for our early stage startup. We love your product! We are super impressed with the features you offer. We highly recommend your product to everyone wanting to work data-driven!
While I would personally <3 this, more than a few people I know need a version of this with Lua/Torch support, with the possiblity that it can hook into NoSQL databases/not run off of your servers in order to run off of selections of really big datasets for research purposes. (They are becoming Spark-Tastic usually on a graph structure because of nature of problems - so sometimes SQL, sometimes not, but either way, big.) @bennstancil -ideas of similar companies that are in a way non-competitive because they are the Lua people not Python people/timelines for Luo or NoSQL/Spark/Off-Site hosting Because these things help deal with data politics. My most/least favorite things
@shanacarp Hi Shana! We have a couple philosophies when thinking about languages like Lua (as well as R, Julia, and others). Mode started as a tool that only supported SQL and a couple databases. Today, we support a number of different types of databases (including SQL-like DBs like Presto, Hive, and BigQuery), Python, and Javascript visualization languages. Mode isn't built to be tied to one language, but instead aims to fit into a workflow, regardless of which languages it incorporates. And how we define and understand that workflow comes from feedback from our customers and the community (so thanks for sharing!). We also want to make sure that we're allowing analysts and data scientists to play on their home court, not ours. We want to enable people to work in the languages they already know (whether it's a particular flavor of SQL, Python, or a language like Lua). That means if we move toward tools like Lua, we want it to be as "native" as possible. So, while we don't support these things currently, we hear you. In the meantime, I unfortunately don't know of any services that offer this combination all at once (which is one reason why we built it - we wanted it for ourselves). Are there any particular aspects to Mode that you like, or would want to see in other tools? Finally, regarding off-site hosting, we aren't planning on moving that way any time soon. That said, we are looking into ways to enable folks to run Python on much larger machines, which would allow data scientists to scale up their Python environments to something much bigger than what they can use locally.
@bennstancil so this goes into a much deeper conversation about the idea of "data politics" (ok I made up that term, but it is a truth) which is way longer than a post on product hunt could cover. I'll give you a starter example, but the full conversation is really an email/call because I've seen these issues go very deep in organizations and I want to get a better feel on what you think/need from the outside EG: I've seen various reactions to me when I say "I dislike SQL and I also really dislike excel for larger projects, and therefore I fully have switched over to python when I can, or google sheets with javascript if you really need a spreadsheet*" All of those reactions are external to the data and questions at hand, or work, because processes I never fully "got" SQL as a language. I also dislike how different implementations treat the actual spec - especially roles and assignments and where the actual "primary data source" is when you have a database accessing data from another table in a different database and pseduo copying it over. I have a deep terror of deleting everything - and that is before the frustration of not being able to poke at the system while "fake tables" are being created in order to get the best quality merges. Between all of this, I think the idea of using a more fully fledged coding language with a strong barrier of roles embedded in it a much safer idea, since the way things are defined in something like python (ducktyping), or even C or Java where you have to declare type is just very different than SQL itself. I've thought about it seriously enough to wonder if I, who I don't think is a particularly good engineer/coding person and is someone who really dislikes SQL, should try to build on top of PANDAS + a few other funday sunday libraries to extend out PANDAS to allow it to send merge operations to SQL written in python, and then get back a dataframe. (all of the major set operations are already in PANDAS/scipy/numpy, the biggest problem is when you need to do merges in merges, or something complicated). Excel is just crashy past a certain size and bad at versioning. While I can do all of the same things, why bother when I can do them faster with python and have versioning? *google sheets' macro language is javascript