Why we don't have a model picker
A question we get from customers (and occasionally from investors) is why we don't expose a model picker the way Cursor does.
The short answer is that we're building for a different user. Cursor's users are developers; picking between GPT-5 and Claude is a meaningful choice they're equipped to make. Our users include CFOs, sales leaders, customer success reps. For them, model choice is friction at best, and at worst a new vector for self-doubt. A marketing director second-guessing a revenue number because they're not sure whether they picked the right model is exactly the failure mode we're trying to design out of analytics.
Slack Data Agent - Ask about your data without leaving Slack
📬 Introducing new ways to share your data
Side note: We're live on Product Hunt today with our Slack Data Agent!
Export to Excel
You can now export to Excel (.xlsx) anywhere you could already export data. Charts, tables, markdown tables, and in-browser record views all get a native Excel option right alongside CSV, so the data you pull out of Basedash lands in a real spreadsheet formatted columns and all instead of a raw text file you have to clean up first.
💬 AI data access shouldn’t require leaving Slack
We re live on Product Hunt today with our Slack Data Agent.
Basedash started as a way for teams to explore, query, and visualize their data in a shared workspace.
📄 How we paginate queries across every SQL dialect
We had a comment in our codebase that said SQL Server doesn't handle pagination well, so we should just avoid pagination for now. And it did exactly that: shipped the entire result set to the browser and let it sort itself out. Same deal for Spanner.
A lot of Basedash is just "run the SQL the user wrote, show the rows." We support 10+ dialects (Postgres, MySQL, BigQuery, Snowflake, Athena, SQL Server, Spanner, and friends), and every query gets paginated because we can't stream a 12M row result set to a browser.
✂️ How we cut our client bundle by 30%
Someone on the team finally looked at our production client bundle, which we hadn't checked in a while, and it was 25.67 MB. We got it down to 18.34 MB without removing a single feature. Most of the wins were stuff we were shipping to customers that had no business being there.
Bundle size is the metric that drifts up one dependency at a time until somebody notices. We noticed, turned on rollup-plugin-visualizer, and read the treemap. That treemap is the most useful 30 seconds of the whole project. You stare at the rectangles and immediately have opinions about every one of them.
New in Basedash: SQL definitions 📘
SQL definitions: reusable snippets across your queries
You can now create SQL definitions scoped to a database connection versioned, named SQL snippets that you can reference inline in any query with {{ definition("name") }}. Definitions get their own home in the Data page sidebar where you can create, edit, describe, and preview them, and the expansion is applied both for human-run queries and for queries the chat agent runs on your behalf.
The chat agent understands definitions too, so when it writes SQL it can reach for your team s definitions automatically. Admins can also let the agent propose and save new definitions when it spots a pattern worth keeping around so the SQL your team relies on becomes a real, reusable building block instead of something everyone re-types.
What was killing our healthy Kubernetes pods
Last week one of our web pods restarted 11 times in 24 hours, and another restarted 9 times. The app worked, users were happy, and latency was fine. Our application logs had nothing to say about it, just gaps where a process used to be.
We spent a couple of days chasing the wrong thing. Then we found a Kubernetes default we d never thought to override, and the crash loop stopped.
