superset is and open source alternative that is comparable, alternatively other platforms such as Explo charge by user groups or customers such that a group of users viewing the same data and dashboards is only charges as 1 user
HN user
anchen976
andrew at explo
With the recent Rockset acquisition news, we've been doing some research and talking to other database solutions to provide alternatives specifically for users who are syncing data from dynamoDB to Rockset for analytics uses cases.
We've compiled a few options here, curious what others are doing or any other suggestions.
We use highcharts to power most of our charting (we're an embedded analytics platform) and switched over from from chart.js
It's fairly powerful but also looks more polished out of the box. Some limitations on styling but that depends on your application/use case.
How is this different from something like https://cube.dev/
We’re Andrew, Austin, and Carly and we’re the creators of Explo's new report builder(https://explo.co/report-builder).
Embed the report builder in your application, and your users can select the data they're interested in, filter, sort, and export the data as a CSV or PDF.
Over the past year, we've worked on an embedded dashboard solution to allow companies to share metrics, data, and insights with their users. However, our customers were still receiving requests for data dumps. Their customer service reps often triaged these data requests, had their data teams pull the data by writing SQL, and emailed large CSV files. For example, an ed-tech platform we recently worked with wanted to allow teachers and admins to pull student rosters, but each user was interested in a different set of fields such as age, grades, contact info, etc. Because of this, they often created customer reports in Jaspersoft or wrote custom SQL queries that took time to do for each request.
That's why we built out the Explo report builder. It leverages the existing Explo platform that connects directly to any SQL database or warehouse and filters the data by customer. To set up the report builder, you write SQL to create the table you want expose, format the data, and embed the report builder in your existing web app.
Check out a demo (https://demo.explo.co/report) for the report builder here or a quick video walkthrough here (https://www.youtube.com/watch?v=OHJnII-DteA&ab_channel=Explo). We're building out much more functionality here including the ability to perform aggregations, pivot the data, save reports, and more.
One question on our minds as we continue down this path is how self-serve do you want your data and analytics to be? Does it make sense for your customers to build their own dashboards and reporting in-app? We learned that it's actually quite rare for users to want to build out their own dashboards in the products they use. If they do want to perform more ad hoc analysis, it often makes sense to just export the raw data, and run the analysis elsewhere. Or pull the data directly into a data warehouse to analyze there.
We'd love to chat with anyone who has built a reporting tool in-house for their own product. What additional functionality did you build out that was helpful for your users? If not, how do you currently deal with data requests and share data?
Explo is different from the other SAAS tools as it's designed specifically for external use cases, so our platform is built with features such as security, flexible design, responsiveness, and version control as first class principles.
Wow the QR code resurgence is real! I'm curious why you chose to support data sources such as Mongo and google sheets first as oppose to others I saw that were coming soon (Postgres, MySQL, etc) and challenges you experienced building out the connections. Looks like we support a completely different set of databases.
And is your data pulled directly from your MRP system or loaded into another database first?
And we'll definitely be adding more examples and videos creating and embedding dashboards in Explo.
Great - will reach out!
Our initial idea was a platform to digitize the restaurant cookbook! We wanted any chef or restaurant to be able to publish recipes and other food content on our platform.
For consumers, this would be a curated recipe platform with recipes from the best chefs as oppose to random users. For chefs and restaurant owners, this would give them an outlet to publish recipes and promote their work without the need to sign book deals and contracts that are often very unfavorable (unless you're already a celebrity chef).
We tried pitching various iterations of this idea to get restaurants onboard, but unfortunately we weren't able to sell them a platform that didn't immediately boost sales.
Scalability is definitely something we're thinking about. Agreed that a single replica DB probably won't work well after a certain extent. Currently we do help customers to set up a data warehouse and optimized data model in Snowflake or other sources if needed.
We also refer customers to services or contractors who help them set up a their data infra to fit their needs as it's not the core focus of our product.
We have also thought about implementing a caching layer to improve performance, although that adds a few hurdles regarding data privacy and pulling live data.
Great question! Explo is designed specifically for embedding, so our product is designed with features such as design flexibility, security, and responsiveness top of mind.
We allow users to customize the design of their dashboards using CSS and Markdown, and have design elements such as containers to group analyses together. We found that users were hesitant to embed Tableau, Quicksight, or other BI dashboards because they didn't fit into their application.
Also, Quicksight and a number of other tools require you to define a data model, create analyses, and then add them to dashboards. Our platform is oriented around the dashboard, so you write SQL, create visualizations, and design dashboards all in the same view. This gives users a lot of flexibility when creating dashboards and also speed up the time to implementation.