The interface lacks punch. While the idea of making a self-serve BI tool which can plugin the gap of bringing better understanding around data is super-cool, the execution here for sure needs work. Tried it out and it's cool for someone to hack with right now.
Thanks. We've just recently announced the very first version, and looking forward to any feedback and feature requests. Will do our best to make interface punchy!
I was interested in this product, but no thanks. At the very least if you're not ready to commit you could provide "beta" pricing for a year until you get that figured out.
Because they allow third parties to build bigger ID graphs and audiences for ad targeting.
By all means, have them for convenience for those users who want to use them, but for the rest of us who know better, we’d appreciate the option to provide you our burner/one-time email addresses.
We're going to extend the way to login for the cloud version.
Currently, email/password auth is available only in self-hosted version (docker image installed on your VPS). Feel free to reach out to me info@tablum.io, if you'd like to test it. Thanks.
because this is a tool for doing work? Nobody (or very few) HN people are going to want to do BI with their facebook accounts, if we even have FB accounts.
Outlook is bigger than Google for corporate email. I would suggest adding that (or better yet, listen to the other feedback and allow a standard email login flow).
Pretty much what the others here have been pointing out, that I have to hand over my data before I can evaluate whether or not I trust you with it. Feel free to verify the email I use to prevent abuse.
I've been evaluating a lot of products in this space in the past week and I think it is a space that could do with a developer-first approach. But to do that I still want to see a path towards using it at scale that's a little more fleshed than a "talk to sales" equivalent. Even if this were open source, I would be happy to pay for someone else to host and scale it, but at least I would know I couldn't be unreasonably locked in after making my business depend on it.
There are desktop alternatives (such as Easy Data Transform, Alteryx and Tableau Prep) where your data stays on your machine. Which helps with latency, as well as privacy.
+1. Given that prices for products in this space range over several orders of magnitude, I wouldn't spend time evaluating without knowing whether my budget is even in the same ballpark.
Would I expect to spend $1k annually? $10k? $100k? More?
Just curious- how does it stack against Metabase (https://www.metabase.com/product/) for example? I used Metabase a few years back and was really blown away with the ease of use.
Thanks! Well, in general they both are self-service BIs, and have common features. Yet, TABLUM.IO is focused more on faster data extraction from files e.g. you can just drag and drop JSON, XML or CSV file to load data from it. Or specify an URL for data loading from remote host. Then it is stored in a local storage as a "view" (similar to sql table). And you can work with it like it is an SQL table using sqlite syntax: JOIN with other loaded data, filter, clean up, export or generate charts. Of cause, it has connectors to popular DBs such as postgres, mysql and clickhouse.
Ultimately, we're working towards a faster data analysis so you won't spend too much time setting up connectors to files and databases. Just get the results as fast as possible.
Same with data analysis: it has embedded support for aggregate - and window-functions. You can get "MOVING AVERAGE" just clicking the table columns (no keystrokes required).
Dashboards are not yet implemented, but we're working on it.
I’ve tried many no code tools over the decades. As an individual and as a group.
Ease of use is really important. But I think easy for Python programmers is better than easy for people to click. Logic is logic, so whether you program in code or via some wack gui, you still need programmers.
Every time it’s come down to regretting committing to a closed, proprietary “programming language” that is the no code tool.
The exception is for simple stuff. But with data projects simple projects usually get complicated fast. So Id rather use a tool that scales well rather than one that starts easy but then is very hard to scale.
I would call TABLUM.IO - a low-code tool.
Power SQL user can type any complex SQL query in the SQL console. Whereas the beginners won't spend much time doing simple "SELECT" or calculating the average, they can just click on the header of the table and select "stats" to see the result.
I agree that no-code is limited to some general scenario, but there're still a lot of them.
Thus, we decided to leave an opportunity to choose which way to go: use mouse for simple / general actions or use SQL console by power users to archive some complex results.
Totally agree with this comment. This sort of "no-lock-in" thinking is exactly what inspired Mito [1] (I'm a co-founder, FYI).
Mito is low-code data analysis tool inspired by spreadsheets. When you edit the spreadsheet, Mito generates Python code directly into your Jupyter lab notebook.
The benefit here is that there's no lock in. If Mito support the action the user wants to take, they can use Mito for a quick point-and-click experience. If not, they can just write Python code as they normally do!
No-code BI and ETL tools are intended mainly as a replacement for Excel, not a replacement for Python.
If you are an accomplished Python programmer, you might code a solution or (e.g. if you want to do something ad hoc quickly) use a no-code tool.
If you aren't a programmer, your choice is typically: learn Python, use Excel, wait for a programmer to do it for you or use a no-code tool. A no-code tool will often be by far the best solution.
You are completely right. Just wanted to add that Excel is a great product and it can be considered as a BI tool. The only thing it lacks of is data merging. You can easily merge data across sheets but it becomes a challenging task when you need to merge/“join” data from databases, especially huge datasets. This is where the self-service BI tools come into play.
TABLUM.IO simplifies data extraction/load/import from files, web and databases. You can load data from postgres, json file and application API, then merge data into a single table, display as a sheet and draw a chart for it. Wheres it is almost impossible with Excel or GoogleSheet.
> Logic is logic, so whether you program in code or via some wack gui, you still need programmers.
Perhaps, depending on your definition of programmers, but lots of people can use logic. An accountant making complex calculations and forecasts in Excel is surely just as logic and precise as a programmer hacking something together in Python.
Agreed, low-code is the happy middle ground here. Code is the most concise way to express what you want to do with data, so tools should just embrace that instead of hiding it away.
We're running a low-code internal tool builder and everything is built / configured with code, but you never start from scratch, so it's 50x more productive then building your own.
Not to be flippant, but in what way is Excel not a no-code / self-service BI / Data Analytics tool? Or where Google Sheets is heading? Serious question. The average non-technical user goes first to Excel or Excel-like things.
Excel doesn't have a lot of visual based development features aside from the tabular structure and graphical data and function reference. People still have to understand function calls and conditionals which aren't represented in what I would call verging on "no-code" ideals.
Excel applications also tend to start rather innocently where something rather simple is programmed in the cellular structure. People quickly feel empowered and begin adding more and more dynamic aspects. At some point spreadsheet based applications turn more into some unmaintainble monstrosity that have all sorts of business and application logic embedded in them that need to get handed elsewhere and someone else familiar with "code" or software design has to translate everything to.
I've been involved in more of this than I care to admit for business applications and it's usually a nightmare because the applications become more critical to the business than anyone but the spreadsheet maintainer is aware of. Suddenly something new and time critical is needed or an error is discovered and the person who created it largely can't remember everything they created and why, so it turns into an software archeological endeavor.
I've seen notebooks with dozens of sheets containing all sorts of embedded data structures on different sheet with all sorts of relationships inside and outside of sheets and nightmare chains of conditionals added in that I've had to sift through.
Sometimes the user then discovers macros or VBA and it becomes a dice roll if things are better or worse (usually better because at least you can quickly follow all the embedded relationships even if they're not well structured unlike logic embedded in cells with all sorts of spatial references you need 10 copies open to trace and debug).
Excel is hardly "no code" it just has a nice beginner learning curve that gets people into dangerous situations before they know they are. I'm not entirely sure about the direction of Google Sheets as I haven't used it in years.
My workflow for the longest time has been: use a SQL GUI to run SQL queries but then dump that to CSV so I could load in Excel and make graphics I could embed in a presentation or sent in an email.
I don't think Excel or Google Sheets are the right interface for diverse data sources that have different query styles and different connection types. Visually the space in each Cell is just pretty constrained.
I am building an open source tool [0] for these kinds of workflows where you need to combine queries, scripting in Python/JavaScript/etc, graphing, dashboards, email exports in one place. It's very similar to tablum.io (this post) but instead of doing any ETL it's just a smart client for joining data client-side.
This was my observation as well. Sheets is actually quite good, but what's missing is connectivity to other tools (e.g. your database). This is exactly the problem we're going after with Wax[0]. We let you deeply integrate Sheets into your other apps.
This is the early stage product launch, the product is completely free for now. So no worries regarding the pricing and charged, you will not be asked about credit cards. Feel free to test it. We do it mostly to collect feedback on the missing features and workflow. Thanks!
Most of the self-service or no-code BI, ETL, data wrangling tools are am aware of (like airtable, fieldbook, rowshare, Power BI etc.) were thought of as a replacement for Excel: working with tables should be as easily as working with spreadsheets. This problem can be solved when defining columns within one table:
Different systems provide different answers to this question but all of them are highly specific and rather limited.
Why it is difficult to define new columns in terms of other columns in other tables? Short answer is that working with columns is not the relational approach. The relational model is working with sets (rows of tables) and not with columns.
One generic approach to working with columns in multiple tables is provided in the concept-oriented model of data which treats mathematical functions as first-class elements of the model. Previously it was implemented in a data wrangling tool called Data Commander. But them I decided to implement this model in the Prosto data processing toolkit which is an alternative to map-reduce and SQL:
It defines data transformations as operations with columns in multiple tables. Since we use mathematical functions, no joins and no groupby operations are needed and this significantly simplifies and makes more natural the task of data transformations.
Moreover, now it provides Column-SQL which makes it even easier to define new columns in terms of other columns:
Not exactly. Timing is the issue when it comes to mixed type of data sources. try to load data via the URL (e.g. the results of API invocation or rss feed), then merge it with the data from postgres sql table or data from CSV file. It becomes challenging with the listed tools. Whereas TABLUM.IO solves the issue and make it organic and fast.
58 comments
[ 2.9 ms ] story [ 119 ms ] threadEarly launch.
I was interested in this product, but no thanks. At the very least if you're not ready to commit you could provide "beta" pricing for a year until you get that figured out.
Just curious, why the social logins are bad?
By all means, have them for convenience for those users who want to use them, but for the rest of us who know better, we’d appreciate the option to provide you our burner/one-time email addresses.
OK. That's compelling enough.
> Just curious, why the social logins are bad?
How uniquely identifying are they to be honest?
My boss would not be happy if I had to use a Facebook account on my work machine.
And who evaluates BI tools in their free time?
I've been evaluating a lot of products in this space in the past week and I think it is a space that could do with a developer-first approach. But to do that I still want to see a path towards using it at scale that's a little more fleshed than a "talk to sales" equivalent. Even if this were open source, I would be happy to pay for someone else to host and scale it, but at least I would know I couldn't be unreasonably locked in after making my business depend on it.
Would I expect to spend $1k annually? $10k? $100k? More?
Just curious- how does it stack against Metabase (https://www.metabase.com/product/) for example? I used Metabase a few years back and was really blown away with the ease of use.
Ultimately, we're working towards a faster data analysis so you won't spend too much time setting up connectors to files and databases. Just get the results as fast as possible.
Same with data analysis: it has embedded support for aggregate - and window-functions. You can get "MOVING AVERAGE" just clicking the table columns (no keystrokes required).
Dashboards are not yet implemented, but we're working on it.
Thanks!
I’ve tried many no code tools over the decades. As an individual and as a group.
Ease of use is really important. But I think easy for Python programmers is better than easy for people to click. Logic is logic, so whether you program in code or via some wack gui, you still need programmers.
Every time it’s come down to regretting committing to a closed, proprietary “programming language” that is the no code tool.
The exception is for simple stuff. But with data projects simple projects usually get complicated fast. So Id rather use a tool that scales well rather than one that starts easy but then is very hard to scale.
I agree that no-code is limited to some general scenario, but there're still a lot of them.
Thus, we decided to leave an opportunity to choose which way to go: use mouse for simple / general actions or use SQL console by power users to archive some complex results.
Mito is low-code data analysis tool inspired by spreadsheets. When you edit the spreadsheet, Mito generates Python code directly into your Jupyter lab notebook.
The benefit here is that there's no lock in. If Mito support the action the user wants to take, they can use Mito for a quick point-and-click experience. If not, they can just write Python code as they normally do!
[1] https://trymito.io/hn
If you are an accomplished Python programmer, you might code a solution or (e.g. if you want to do something ad hoc quickly) use a no-code tool.
If you aren't a programmer, your choice is typically: learn Python, use Excel, wait for a programmer to do it for you or use a no-code tool. A no-code tool will often be by far the best solution.
TABLUM.IO simplifies data extraction/load/import from files, web and databases. You can load data from postgres, json file and application API, then merge data into a single table, display as a sheet and draw a chart for it. Wheres it is almost impossible with Excel or GoogleSheet.
Perhaps, depending on your definition of programmers, but lots of people can use logic. An accountant making complex calculations and forecasts in Excel is surely just as logic and precise as a programmer hacking something together in Python.
There’s a difference between being able to program (everyone) and being a professional programmer.
It’s like everyone can cook dinner but not all can be a chef. This doesn’t mean the solution is microwaveable meals for everyone.
We're running a low-code internal tool builder and everything is built / configured with code, but you never start from scratch, so it's 50x more productive then building your own.
Contrast this with a video like this one: https://www.youtube.com/watch?v=WuIS-m0B2cY
After watching the above, I'm more curious to check out the real product.
Excel applications also tend to start rather innocently where something rather simple is programmed in the cellular structure. People quickly feel empowered and begin adding more and more dynamic aspects. At some point spreadsheet based applications turn more into some unmaintainble monstrosity that have all sorts of business and application logic embedded in them that need to get handed elsewhere and someone else familiar with "code" or software design has to translate everything to.
I've been involved in more of this than I care to admit for business applications and it's usually a nightmare because the applications become more critical to the business than anyone but the spreadsheet maintainer is aware of. Suddenly something new and time critical is needed or an error is discovered and the person who created it largely can't remember everything they created and why, so it turns into an software archeological endeavor.
I've seen notebooks with dozens of sheets containing all sorts of embedded data structures on different sheet with all sorts of relationships inside and outside of sheets and nightmare chains of conditionals added in that I've had to sift through.
Sometimes the user then discovers macros or VBA and it becomes a dice roll if things are better or worse (usually better because at least you can quickly follow all the embedded relationships even if they're not well structured unlike logic embedded in cells with all sorts of spatial references you need 10 copies open to trace and debug).
Excel is hardly "no code" it just has a nice beginner learning curve that gets people into dangerous situations before they know they are. I'm not entirely sure about the direction of Google Sheets as I haven't used it in years.
I don't think Excel or Google Sheets are the right interface for diverse data sources that have different query styles and different connection types. Visually the space in each Cell is just pretty constrained.
I am building an open source tool [0] for these kinds of workflows where you need to combine queries, scripting in Python/JavaScript/etc, graphing, dashboards, email exports in one place. It's very similar to tablum.io (this post) but instead of doing any ETL it's just a smart client for joining data client-side.
[0] https://github.com/multiprocessio/datastation
0 - https://www.wax.run/
No, thanks.
Yet, the main problem is in working multiple tables: how can we define a column in one table in terms of columns in other tables? For example:
Different systems provide different answers to this question but all of them are highly specific and rather limited.Why it is difficult to define new columns in terms of other columns in other tables? Short answer is that working with columns is not the relational approach. The relational model is working with sets (rows of tables) and not with columns.
One generic approach to working with columns in multiple tables is provided in the concept-oriented model of data which treats mathematical functions as first-class elements of the model. Previously it was implemented in a data wrangling tool called Data Commander. But them I decided to implement this model in the Prosto data processing toolkit which is an alternative to map-reduce and SQL:
https://github.com/asavinov/prosto
It defines data transformations as operations with columns in multiple tables. Since we use mathematical functions, no joins and no groupby operations are needed and this significantly simplifies and makes more natural the task of data transformations.
Moreover, now it provides Column-SQL which makes it even easier to define new columns in terms of other columns:
https://github.com/asavinov/prosto/blob/master/notebooks/col...
- https://rows.com/
- https://www.rowshare.com/
- https://www.airtable.com/
- fieldbook
- Power BI