41–50 of 116 posts
Mathesar ( https://news.ycombinator.com/item?id=34999774 ) was the last one I tried out but it couldn't support more than 250k rows without crashing and required foreign keys in order to infer relationships. Otherwise it's exactly what I want. An Excel/Airtable interface around a raw database connection.
How does Outerbase compare?
Edit:
Mistypes
I would even take this further and hide the SQL altogether, and make this accessible via Slack/Teams bot.
Will this be the interface that I need? Mathesar ( https://news.ycombinator.com/item?id=34999774 ) was the last one I tried out but it couldn't support more than 250k rows without crashing and required foreign keys in order to infer relationships. Otherwise it's exactly what I want. An Excel/Airtable interface around a raw database connection. How does Outerbase compare? Edit: Mistypes
To be entirely candid and honest, returning a lot of rows presents problems on our end as well at the moment. It's something we are actively working on improving for large data sets to create the best user experience without having to concern yourself about what you're returning.
For our EZQL (natural language to SQL) you don't necessarily need to have foreign keys to infer relationships between tables. We try to infer those relationships for you.
This is very cool, one usecase I definitely see for this is letting PMs get the answers they want without bothering eng. I would even take this further and hide the SQL altogether, and make this accessible via Slack/Teams bot.
I need answers from queries in the DB but I don't have DB access and having me write sql queries is a waste of time.
This is very cool, one usecase I definitely see for this is letting PMs get the answers they want without bothering eng. I would even take this further and hide the SQL altogether, and make this accessible via Slack/Teams bot.
As a PM in a previous life, this is dead on. I need answers from queries in the DB but I don't have DB access and having me write sql queries is a waste of time.
Not true in my experience. True at very large / very mature companies, but at any In that same vein, in a small company environment you don't harass engineers with query requests, you learn SQL. I've seen hundreds of non-technical users do this (and helped many of them), it's not unusual. Visual query-building tools never help. Even good interfaces like Looker, on top of carefully-crafted data warehouses (which most won't have) are still vastly inferior to SQL and so analysts don't use them. Again, just trying to suggest the problem may not be what you think.
Generating queries with a language model won't work. Real data is far messier than you expect. The table names and field names will not be as literal as you need them to be, and half the database will come with "special instructions" (like "oh you need to divide that field by 100 because...") that will not be inferrable from the names or the data. Many DBs will completely lack foreign keys or consistent key naming. There will often be epochal "eras" in the data where everything before YYYY-MM-DD worked like X, and after that it's Y, and the value of that date is recorded nowhere.
"Currently we support Postgres, MySQL, Snowflake, BigQuery, and Redshift."
I know Java isn't hip but consider relying on JDBC for DB access. There are more DBs out there than you can imagine, and 100% of them support JDBC. Otherwise there will always be some DB you're not supporting, and adding that support will be costly.
Anyway just some food for thought. Good luck. (about me: 18 years in data & analytics)
"Databases are usually locked down to a few team members..." Not true in my experience. True at very large / very mature companies, but at any In that same vein, in a small company environment you don't harass engineers with query requests, you learn SQL . I've seen hundreds of non-technical users do this (and helped many of them), it's not unusual. Visual query-building tools never help. Even good interfaces like Lo…
In an earlier comment you mentioned evolving into a BI dashboarding tool. I'm interested to learn more about this roadmap and how you'd differentiate yourself from Power BI and Tableau?
Today's large tools require in-depth specialized knowledge on the data as well as how to apply it to create dashboards. Our mission is to create data tools that non-developers can understand, use, and create impact with on day 1.
One feature we're really excited about is how to hold a conversation with your database to fine tune the chart you want in natural language, and have "verified" sources come in to double check what has been produced meets the expectations of the business. Certainly a lot more things on the way as well.