Launch HN: BaseDash (YC S20) – Edit your database with the ease of a spreadsheet
100 comments
The main question I have with tools like this is around safety.
The reason we typically don't directly edit production data like this is because of application level concerns or validation.
I think it's important that any tool like this allows a way to replicate that safety in some way, otherwise it's as risky as using a GUI client directly. Access control (which this does) addresses security and starts addressing safety, but there's a lot more necessary to get to the safety that is often enforced at the application level.
There's an argument that the validation should be in the database, and that's nice when it's possible, but it's often not. For any application using Rails/Django, anything else along those lines, anyone interacting with the database mostly via an ORM, will typically not be putting this sort of validation in the database in _all_ cases – thinking about enums, fixed slugs, relative dates, timezone support, etc.
The reason we typically don't directly edit production data like this is because of application level concerns or validation.
I think it's important that any tool like this allows a way to replicate that safety in some way, otherwise it's as risky as using a GUI client directly. Access control (which this does) addresses security and starts addressing safety, but there's a lot more necessary to get to the safety that is often enforced at the application level.
There's an argument that the validation should be in the database, and that's nice when it's possible, but it's often not. For any application using Rails/Django, anything else along those lines, anyone interacting with the database mostly via an ORM, will typically not be putting this sort of validation in the database in _all_ cases – thinking about enums, fixed slugs, relative dates, timezone support, etc.
Definitely agree with this. As you mentioned, we currently support database-level validation (anything data type related, foreign keys, etc.), still trying to figure out the best way to handle ORM-level validation.
I think ultimately BaseDash would hook into your existing validations (e.g. through models.py) to handle this.
I think ultimately BaseDash would hook into your existing validations (e.g. through models.py) to handle this.
The problem with hooking into existing validations is that those are arbitrary Python code (or whatever language is being used).
This means that BaseDash would have to be able to securely execute arbitrary Python code... which means that now you also need to package and deploy the code to BaseDash because you might need libraries, resource files, etc, and now BaseDash is essentially a full-blown deployment target with all the complexity that comes with another deployment process.
I suspect BaseDash wants to avoid this!
One option might be to flip this on its head, and make BaseDash validation libraries that plug into things like Django/Rails, and a) allow serialisation of rules and uploading to BaseDash at deploy time, and b) _disallow_ or warn when that serialisation isn't possible, such as with custom validation.
This option would mean BaseDash doesn't need access to the codebase and deployments are much simpler, but comes at the cost of BaseDash likely needing to provide libraries for most popular ORMs/environments, and at the cost of developer overhead in integrating and customising/maintaining those integrations.
This means that BaseDash would have to be able to securely execute arbitrary Python code... which means that now you also need to package and deploy the code to BaseDash because you might need libraries, resource files, etc, and now BaseDash is essentially a full-blown deployment target with all the complexity that comes with another deployment process.
I suspect BaseDash wants to avoid this!
One option might be to flip this on its head, and make BaseDash validation libraries that plug into things like Django/Rails, and a) allow serialisation of rules and uploading to BaseDash at deploy time, and b) _disallow_ or warn when that serialisation isn't possible, such as with custom validation.
This option would mean BaseDash doesn't need access to the codebase and deployments are much simpler, but comes at the cost of BaseDash likely needing to provide libraries for most popular ORMs/environments, and at the cost of developer overhead in integrating and customising/maintaining those integrations.
> The main question I have with tools like this is around safety.
"Your app's data is never stored on our servers with the exception of edit history which lets you audit all changes to your data" from: https://www.basedash.io/pricing
Not the most convincing sell but not that they did not address this concern at all.
"Your app's data is never stored on our servers with the exception of edit history which lets you audit all changes to your data" from: https://www.basedash.io/pricing
Not the most convincing sell but not that they did not address this concern at all.
He's talking about operational safety - your application applies validation to inputs to the database. This ensures that only valid data is stored.
What happens if you have a field that's supposed to be 0-9, but it's an int field and someone types in 22 on accident? Sure it might be valid for the database, but it's not valid for the application.
There's certainly different ways to take the problem, but it needs to be considered.
What happens if you have a field that's supposed to be 0-9, but it's an int field and someone types in 22 on accident? Sure it might be valid for the database, but it's not valid for the application.
There's certainly different ways to take the problem, but it needs to be considered.
> What happens if you have a field that's supposed to be 0-9, but it's an int field and someone types in 22 on accident? Sure it might be valid for the database, but it's not valid for the application.
This is why database constraints exist.
Any sufficiently long lived database ends up with more than one code base connected to it. Enforcing rules in the database ensures a baseline level of data sanity.
This is why database constraints exist.
Any sufficiently long lived database ends up with more than one code base connected to it. Enforcing rules in the database ensures a baseline level of data sanity.
You are right.
But ....
In the wild, database constraints are rare. I even often see databases without any foreign key constraint.
We have a new client like that. application developed in the past 3 years on postgres, uses all the buzzwords (microservices, Kubernetes, terraform, ...). The only constraints in database is on primary keys. The site moves up to 500k EUR per day.
This is far from rare.
But ....
In the wild, database constraints are rare. I even often see databases without any foreign key constraint.
We have a new client like that. application developed in the past 3 years on postgres, uses all the buzzwords (microservices, Kubernetes, terraform, ...). The only constraints in database is on primary keys. The site moves up to 500k EUR per day.
This is far from rare.
Both your and the parent's sentiments are so on-point. And they're one of the reasons I don't like ORMs or the use of in-app constraint checking. The mid-Aughties rise of CRUD-focused frameworks that treat the database as a sidecar to the web app ignored as inconvenient the full power of an RDBMS, in part because MySQL was the not-full-RDBMS that they were often paired with.
I think a big part of it is a general fear of database migrations. Once you embrace schema evolution as a normal part of development, it becomes natural to have your schemas reflect your true data constraints and relationships. Rather than just unlabeled sacks of text fields.
I remember working on my first full-stack project, I was so intimidated by migrations. Nowadays I couldn't imagine starting even a small side project without writing migrations from the first commit.
Unfortunately, I think a lot of new developers resort to MongoDB because they think it's better for early stage evolving schemas. It's certainly more open to changing your schema on the fly, but perhaps not for the better.
Unfortunately, I think a lot of new developers resort to MongoDB because they think it's better for early stage evolving schemas. It's certainly more open to changing your schema on the fly, but perhaps not for the better.
I think that's a different thing. If we think about a field that is an enumeration (in some form), this might need to deserialise to a language-native enumeration option in the application, or need to have one of a small set of values. If someone puts a typo into that field with this tool that could cause issues in production.
Yes an audit log may help you notice these and fix them, but that's probably not going to be enough for anyone running a product in production off this database.
Yes an audit log may help you notice these and fix them, but that's probably not going to be enough for anyone running a product in production off this database.
I totally understand what you are talking about, having spend years building Django, Yii, Laravel based Business logic and validation and Admins. The way I am tackling this are two:
- My product is on-premise by choice so teams have more confidence about giving 100% access to everything internal
- It will connect directly with your existing logic through APIs (REST) or RPC (I will be going gRPC way)
This means developers will be able to re-use and attach existing logic to the Business dashboard/Admin application which is running separately.
What do you think of that approach?
- My product is on-premise by choice so teams have more confidence about giving 100% access to everything internal
- It will connect directly with your existing logic through APIs (REST) or RPC (I will be going gRPC way)
This means developers will be able to re-use and attach existing logic to the Business dashboard/Admin application which is running separately.
What do you think of that approach?
One of the examples in the splash video is a person incrementing account credit...if I was a finance guy, this would terrify me...
...obviously, technical stuff like consistency seems problematic too.
...obviously, technical stuff like consistency seems problematic too.
This.
We have very complex business logic directly tied to our Rails / ActiveRecord validations (and, btw, they are a blessing).
Also, it's not only validations. We rely heavily on ActiveRecord callbacks, which are awsome. We have hundreds of before_save, after_save, after_create_commit, and so on, all over our models, and they are also indispensable to our business rules.
For a simple example, if I need to sync my User model with Mailchimp after an e-mail update, this tool would not fire the after_commit callbacks.
Having said that, I would definitely pay for a "service" that would act as gem in my application, mount itself on a specific endpoint (think /turbo-admin), and give me the exact same feature set I saw on this landing page, but with the ease of mind that all our updates would go through Rails, running validations and callbacks.
We have very complex business logic directly tied to our Rails / ActiveRecord validations (and, btw, they are a blessing).
Also, it's not only validations. We rely heavily on ActiveRecord callbacks, which are awsome. We have hundreds of before_save, after_save, after_create_commit, and so on, all over our models, and they are also indispensable to our business rules.
For a simple example, if I need to sync my User model with Mailchimp after an e-mail update, this tool would not fire the after_commit callbacks.
Having said that, I would definitely pay for a "service" that would act as gem in my application, mount itself on a specific endpoint (think /turbo-admin), and give me the exact same feature set I saw on this landing page, but with the ease of mind that all our updates would go through Rails, running validations and callbacks.
I just answered above, but to add to your point of the gem, yes that is an approach I have in mind too. Since my product runs on-prem I have a much larger toolbox at hand and can enable companies to execute gem/pip/... packages along with my product.
Of course all these integrations have to be taken care of and I am not there yet, but it is in the choices I have made already.
Of course all these integrations have to be taken care of and I am not there yet, but it is in the choices I have made already.
I work on an app that uses Postgres's Row Level Security for access control. It deliberately makes it very hard to modify data; an app like this one wouldn't ever work for it.
Gotta hand it to you, this looks really slick. Also, the call to action at the bottom was well made;
> Skip the waitlist, this week only
> We're opening access to BaseDash for the next week during our Hacker News launch.
Usually when someone is like “act now” I’m like “yeah right”. But in this case, whether it really matters or not that I sign up exactly this week, the fact that you put some effort into connecting the text to the HN post made it feel more genuine and was sufficient to instead make me go “alright I’ll do it”.
I don’t immediately have time to use it but I can tell that this product is useful so I’m making a mental note to log back in in the future and check it out more. For now I was happy to see that in addition to the UX niceties that were mentioned on the landing page, you guys make it possible to configure a connection with SSH between your servers and the db servers of the user. That is very encouraging to see :)
I think on top of that it would be neat if you also offered users to configure connections that go through Wireguard, as I run Wireguard on my personal server and I know other people do too. I guess one guy asking for Wireguard is probably not going to convince you to add it. But who knows, maybe others will request it too ;)
> Skip the waitlist, this week only
> We're opening access to BaseDash for the next week during our Hacker News launch.
Usually when someone is like “act now” I’m like “yeah right”. But in this case, whether it really matters or not that I sign up exactly this week, the fact that you put some effort into connecting the text to the HN post made it feel more genuine and was sufficient to instead make me go “alright I’ll do it”.
I don’t immediately have time to use it but I can tell that this product is useful so I’m making a mental note to log back in in the future and check it out more. For now I was happy to see that in addition to the UX niceties that were mentioned on the landing page, you guys make it possible to configure a connection with SSH between your servers and the db servers of the user. That is very encouraging to see :)
I think on top of that it would be neat if you also offered users to configure connections that go through Wireguard, as I run Wireguard on my personal server and I know other people do too. I guess one guy asking for Wireguard is probably not going to convince you to add it. But who knows, maybe others will request it too ;)
Thanks! We thought it would be best for HN to have direct access (we didn't do this for Product Hunt).
I'll keep Wireguard in mind :)
I'll keep Wireguard in mind :)
I started on a similar thing a couple of months back but didn’t make it to YC. I talked to a bunch of folks and demoed then an MVP, but couldn’t get any paying users. Covid-19 hit and I had to find a paying job to make ends meet after many months on it.
I open sourced my work to make something out of it. Not as polished as BaseDash or popsql. It’s MIT licensed.
https://github.com/nojvek/boomadmin
Congrats BaseDash on making it to YC and getting this far. I wish you best of luck. Even though I’m a bit jealous.
I open sourced my work to make something out of it. Not as polished as BaseDash or popsql. It’s MIT licensed.
https://github.com/nojvek/boomadmin
Congrats BaseDash on making it to YC and getting this far. I wish you best of luck. Even though I’m a bit jealous.
Don't feel bad. I was in your situation in the past. Don't give up. I have finally been able to launch a quite successful product (being used by a significant people daily). I plan to apply to YC this September. I don't want to put my product here because I don't want to steal thunders from BaseDash.
I believe a majority of YC founders apply multiple times, often across multiple companies. Personally, I started 2 companies, applied 4 times, interviewed 2 times, across 4 years before getting in with BaseDash.
Definitely try again, YC is worth it.
Definitely try again, YC is worth it.
I just asked my CISO, about this product.
He said, "For small, and really small companies they already have the talent to deal with the database directly because that's how they handle most of their problems because they don't have a "console" interface. So this would be just another product for them, and the technical staff wouldn't find it terribly useful because they already know how to interact with the database.
For medium to large companies it doesn't fit because those companies spend all of their time trying to limit direct access to the database, so buying a tool that makes it easier is counter productive.
However, it's a cool idea and looks like it was well implemented."
Oh, I forgot to add that he said "Allowing a 3rd party web site to connect directly to a production database for the purpose allowing direct database manipulation will only happen with companies that don't have a security department, or their "security person" is just in name only. There are so many things that can go wrong that is just not worth doing. Even if this could run on site, is runs against basically all Information Security and IT operations best practices."
He said, "For small, and really small companies they already have the talent to deal with the database directly because that's how they handle most of their problems because they don't have a "console" interface. So this would be just another product for them, and the technical staff wouldn't find it terribly useful because they already know how to interact with the database.
For medium to large companies it doesn't fit because those companies spend all of their time trying to limit direct access to the database, so buying a tool that makes it easier is counter productive.
However, it's a cool idea and looks like it was well implemented."
Oh, I forgot to add that he said "Allowing a 3rd party web site to connect directly to a production database for the purpose allowing direct database manipulation will only happen with companies that don't have a security department, or their "security person" is just in name only. There are so many things that can go wrong that is just not worth doing. Even if this could run on site, is runs against basically all Information Security and IT operations best practices."
> For small, and really small companies they already have the talent to deal with the database directly because that's how they handle most of their problems because they don't have a "console" interface.
I feel like small and really small comparies are the primary market for this tool. A sort of stepping stone until they can build out a large enough engineering team to support more specialized internal tooling. A lot of small companies store most / all of their business data in spread sheets anyway, BaseDash just gives them a more robust backend (SQL) that allows them to transition more seamlessly into custom back office software.
> So this would be just another product for them, and the technical staff wouldn't find it terribly useful because they already know how to interact with the database.
The technical staff would find it tremendously useful because they can focus on building a solid data model on top of a SQL database without having to spend time building out clunky admin interfaces. And from the other direction they don't need to build out migrations from legacy spreadsheet data into a SQL database.
> For medium to large companies it doesn't fit because those companies spend all of their time trying to limit direct access to the database, so buying a tool that makes it easier is counter productive.
Maybe, but if BaseDash offers robust enough validations and permissioning, this shouldn't be as much of a concern. The flip side is that without BaseDash, if some data needs to be tweaked that isn't possible to do using the clunky ad hoc admin interfaces that were built, someone on the engineering team would need to make those changes in the database manually, or ops would need to wait for engineering to build out a feature to allow them to make those changes.
I feel like small and really small comparies are the primary market for this tool. A sort of stepping stone until they can build out a large enough engineering team to support more specialized internal tooling. A lot of small companies store most / all of their business data in spread sheets anyway, BaseDash just gives them a more robust backend (SQL) that allows them to transition more seamlessly into custom back office software.
> So this would be just another product for them, and the technical staff wouldn't find it terribly useful because they already know how to interact with the database.
The technical staff would find it tremendously useful because they can focus on building a solid data model on top of a SQL database without having to spend time building out clunky admin interfaces. And from the other direction they don't need to build out migrations from legacy spreadsheet data into a SQL database.
> For medium to large companies it doesn't fit because those companies spend all of their time trying to limit direct access to the database, so buying a tool that makes it easier is counter productive.
Maybe, but if BaseDash offers robust enough validations and permissioning, this shouldn't be as much of a concern. The flip side is that without BaseDash, if some data needs to be tweaked that isn't possible to do using the clunky ad hoc admin interfaces that were built, someone on the engineering team would need to make those changes in the database manually, or ops would need to wait for engineering to build out a feature to allow them to make those changes.
I see this as a substitute for spreadsheets. I work in Business Intelligence and we spend a fair amount of time importing data from user spreadsheets that need to be incorporated into data warehouse and reports. It is a nightmare of a process because so many things can go wrong. I would jump at opportunity to substitute the spreadsheets for database tables.
Yes, this tool seems ideal for the people who unintentionally create databases in excel. I realize this sounds insulting, but providing tools to the people who know their business is useful. Perhaps you could brand it as MaxS?
Founder of a competing product here. We've built an open source project so that you can self-host and we have role based access. Would love to know what you think!
You can see the project here: https://github.com/appsmithorg/appsmith
$50/user/month seems a bit steep to me, you can easily get something like https://retool.com/pricing/ for $10/user/month. Granted it's a bit of a different market, but it does a lot more in addition to having editable/searchable/filterable DB tables.
For me the pain point is that, like many others, they want to charge the same price for editors and read-only users.
Do the math with me to feel the pain:
-I use the product $50/month great
-My team use the product $300/month (6x50€) bearable if product really fit our need
-My team want to share access in read-only mode with the whole department 2500$/month (50x50) acceptable only if it's a core unavoidable product
Almost everytime there is no real technical difference between hosting service for use case 2 and 3. So I get that the business model intend to milk as much money from large organisations that shit gold and can't do basic math. But in the process you are cutting yourself from all small/medium company that just seek to pay a fair price.
To keep it simple I believe the basis should be that read only are always free or linked to paying (like get 50 read-only license for each paying editor licence). This better reflect real world situation.
Do the math with me to feel the pain:
-I use the product $50/month great
-My team use the product $300/month (6x50€) bearable if product really fit our need
-My team want to share access in read-only mode with the whole department 2500$/month (50x50) acceptable only if it's a core unavoidable product
Almost everytime there is no real technical difference between hosting service for use case 2 and 3. So I get that the business model intend to milk as much money from large organisations that shit gold and can't do basic math. But in the process you are cutting yourself from all small/medium company that just seek to pay a fair price.
To keep it simple I believe the basis should be that read only are always free or linked to paying (like get 50 read-only license for each paying editor licence). This better reflect real world situation.
That's a good point, I'll look into reducing the pricing for read-only users. We haven't had many companies with read-only users so it hasn't come up, but I think it makes sense.
It seems to be the same as the retool pro version with audit logs.
Product looks great, congrats on the launch. I would reconsider the positioning of the product if I were in your shoes.
As danpalmer said, I suspect it might be tricky to ensure data integrity if non-technical people are bypassing app-level validations.
That said, while I may not use this for my mission-critical data, I do think there's a lot of potential in using this as a headless CMS. I'm currently using Airtable, and its API limits make it unusable for anything apart from light workloads. Also, doesn't have webhooks.
But, if I can use BaseDash instead as my CMS and have my marketing team handle the data through a familiar interface, while design + dev source the data into Figma & a static site through an API respectively, I see myself paying for this.
As danpalmer said, I suspect it might be tricky to ensure data integrity if non-technical people are bypassing app-level validations.
That said, while I may not use this for my mission-critical data, I do think there's a lot of potential in using this as a headless CMS. I'm currently using Airtable, and its API limits make it unusable for anything apart from light workloads. Also, doesn't have webhooks.
But, if I can use BaseDash instead as my CMS and have my marketing team handle the data through a familiar interface, while design + dev source the data into Figma & a static site through an API respectively, I see myself paying for this.
Absolutely, we have a couple customers using BaseDash as a headless CMS. Edit history is especially nice here because you can always look through past iterations of content.
I'm really bullish on this concept. I learned how to code coming from a finance background, and the mental shift from Excel to relational database felt natural enough, but the lack of Excel-like ways to interact with those databases has always felt like white space to me. Well done!
We use dbeaver internally (and we hate it). But it is free and our engineers get by with most of what's required from tool like it.
And dashbase looks like a well done product for a new project - what does you stack looks like frontend and backend ?
And have to agree with others that dashbase is pricey though!
It will be nearly impossible to convince management to pay $600 per year.
Can you tell about usecases of your early users who are paying for this ?
And dashbase looks like a well done product for a new project - what does you stack looks like frontend and backend ?
And have to agree with others that dashbase is pricey though!
It will be nearly impossible to convince management to pay $600 per year.
Can you tell about usecases of your early users who are paying for this ?
> We use dbeaver internally (and we hate it).
Why do you "hate" it? (such a strong word!) My only complaint is that I need to invalidate the connection every time I don't query anything for a few minutes, otherwise the next query hangs for like 50 seconds. But apart from that, I think it's great, especially for a free product. And the project is very active, it gets a new release about every 15 days.
Why do you "hate" it? (such a strong word!) My only complaint is that I need to invalidate the connection every time I don't query anything for a few minutes, otherwise the next query hangs for like 50 seconds. But apart from that, I think it's great, especially for a free product. And the project is very active, it gets a new release about every 15 days.
Not the best editor for schema design I would say. MySQL workbench is great in that respect. Wish something of that sort existed for other dbs.
I have NOT come across connection invalidation problem though.
I have NOT come across connection invalidation problem though.
> I need to invalidate the connection every time I don't query anything for a few minutes, otherwise the next query hangs for like 50 seconds
Sounds like you messed up the connection settings, I have never had this problem using DBeaver for years across companies.
Sounds like you messed up the connection settings, I have never had this problem using DBeaver for years across companies.
I'm CTO of a very early stage startup and $50/mo to allow my CEO to read and edit the database is an easy decision.
This is a half-joke of a comment, but I would pay $50/month to a product that could explicitly prohibit the CEO from editing the production database.
I saw this immediately after submitting my comment above and I was like why would you want to give such access to someone who is more than likely non-technical. I can't see any pros from this unless it's locked to read only mode but then at $50 you're just paying for an excel view into your app.
In a startup, are you sure you like to spend 600 bucks on a db edit tool - what stage is your startup ?
I disagree, speaking on production data, if your CEO is technical enough they should be able to do this (for whatever reason they have).
If not, you need some sort of admin interface (could be a couple forms) to address this properly so invalid data can't be plopped in OR any changes should be documented and sent to someone technical even if it's a typo fix. It seems fun and easy but production data isn't something you should wrap in an excel interface and give to any and everyone. $600 a year so your boss can update names and dates is kinda hard to justify as well.
If not, you need some sort of admin interface (could be a couple forms) to address this properly so invalid data can't be plopped in OR any changes should be documented and sent to someone technical even if it's a typo fix. It seems fun and easy but production data isn't something you should wrap in an excel interface and give to any and everyone. $600 a year so your boss can update names and dates is kinda hard to justify as well.
The stack is Node.js with Express and React. We use Sequelize to handle database connections.
As others mentioned, our current pricing is in line with higher tiers of other internal tools, mostly geared towards startups with revenue or funding. We're hoping to add cheaper (and free!) plans moving forward once we validate that we can make money from SMBs.
Early customers are using the product for customer support, order management, basic analytics dashboards, data entry. Good mix of technical and non-technical users within teams.
As others mentioned, our current pricing is in line with higher tiers of other internal tools, mostly geared towards startups with revenue or funding. We're hoping to add cheaper (and free!) plans moving forward once we validate that we can make money from SMBs.
Early customers are using the product for customer support, order management, basic analytics dashboards, data entry. Good mix of technical and non-technical users within teams.
Wow how can you hate DBeaver. Do you even write SQL?
How big is the "spreadsheet as database" market? I mean don't get me wrong, I am a huge fan of spreadsheets. But it seems like there are many products and companies trying to compete in this space.
We're more so positioned as an internal tool, so competing with products like Retool and Internal. Main difference is that BaseDash gives an opinionated interface rather than a UI builder. We're betting that most companies can get away with a really polished Airtable-like interface, saving them from needing engineers to build the UI themselves.
> We're betting that most companies can get away with a really polished Airtable-like interface, saving them from needing engineers to build the UI themselves.
Yes! If you add to this [0] a managed database offering of your own (ala airtable) and make it tres simple to (ab)use, then that'd be something. All the best.
[0] database is the app?
Yes! If you add to this [0] a managed database offering of your own (ala airtable) and make it tres simple to (ab)use, then that'd be something. All the best.
[0] database is the app?
I actually liked this idea when it came up in my customer conversations and I have this in the roadmap of my product. This space is definitely going to get more mature and I feel Airtable is a big inspiration for me. Making it easy for non-technical teams to add new Tables and do complex queries (I mentioned in separate comment here) is what I feel will be a differentiator for me.
We actually had a 1-month-long pivot to managed database hosting early on in development, but it was super janky. Might look into this again in the future.
There is no way that my current organization would buy this, but it would free up a lot of developer hours if customer support or even operations analysts could do this instead of needing a dev every time they wanted to run a custom report.
I would be really interested in knowing why your organization will not buy this. I am the founder of a product in the same space, not launched, not in YC. But it is open core and on-premise and will integrate deeply with existing business logic with APIs or RPC. So I am really curious.
I can think of a few:
- Companies where editing the dB can have a large impact (eg banks) - Companies affected by privacy regulations (eg GDPR) - Companies where outages are expensive (eg Operations systems) - Companies where the database is valuable and export risk is high (eg customer data).
- Companies where editing the dB can have a large impact (eg banks) - Companies affected by privacy regulations (eg GDPR) - Companies where outages are expensive (eg Operations systems) - Companies where the database is valuable and export risk is high (eg customer data).
You can track changes and see comments as to why each change was made, that's really cool.
They should use this as their main selling point.
How does this differ from something like DBeaver? Our QA Analysts (semi-manual testers) use that for making tweaks to our databases, both production and otherwise. Developers also use it because it is frequently easier than the command line when we do not know all the table and column names.
Is it basically a less intimidating version of that?
Is it basically a less intimidating version of that?
Yes, it's meant to be much easier for non-technical teammates, plus has more collaborative functionality built for teams (easy to share access, team-wide edit history, real-time collaboration).
I tend to think of tools like DBeaver as being built for individual, technical users, while BaseDash is built for cross-functional teams.
I tend to think of tools like DBeaver as being built for individual, technical users, while BaseDash is built for cross-functional teams.
Huge shout out to DBeaver by the way, it's one of the most useful applications I use on a daily basis.
A few folks mentioned repositioning so I thought I'd suggest a possibility.
Medium/large companies do want to restrict access to production databases. Especially sysadmin level access.
Maybe your tool could help companies with this. A coder/dba/support person can author an SQL "workbook" against their favorite dev db (thinking something like Jupyter Lab). They then submit the workbook for execution against a test or production db (with specific set of permissions like readonly, update X,Y,Z tables, etc).
Make sure everything run against production is audit logged (who did what, what data was viewed, what changes were made).
Also a bit of a front end workflow around getting access to production (dev submits request for access, some sort of production supervisor grants access, limited access (workbook requires review), or declined.
Anyways just some random thoughts.
(very slick website and feature walk throughs. impressive stuff)
Medium/large companies do want to restrict access to production databases. Especially sysadmin level access.
Maybe your tool could help companies with this. A coder/dba/support person can author an SQL "workbook" against their favorite dev db (thinking something like Jupyter Lab). They then submit the workbook for execution against a test or production db (with specific set of permissions like readonly, update X,Y,Z tables, etc).
Make sure everything run against production is audit logged (who did what, what data was viewed, what changes were made).
Also a bit of a front end workflow around getting access to production (dev submits request for access, some sort of production supervisor grants access, limited access (workbook requires review), or declined.
Anyways just some random thoughts.
(very slick website and feature walk throughs. impressive stuff)
The product looks cool but i seriously doubt if something like this can fly in any of our production services where changes can be made directly to a production database without an audit trail. Even the example on the website where the account credit is being increased is something that I've yet to see in a production system. To safely use it on a production system internally it would have to be deployed on premise.
In addition to that, the TOS clearly wash their hands if something goes wrong. I use airtable extensively in my personal projects and at work which seems to work fine.
One more thing i observed about the company structure is that they're based in Delaware in a virtual office. Now, i know that as startups go, this isn't unheard of but trying to get this past legal would be nightmare.
Congratulations on the launch though.
In addition to that, the TOS clearly wash their hands if something goes wrong. I use airtable extensively in my personal projects and at work which seems to work fine.
One more thing i observed about the company structure is that they're based in Delaware in a virtual office. Now, i know that as startups go, this isn't unheard of but trying to get this past legal would be nightmare.
Congratulations on the launch though.
We have edit history which acts as an audit trail for changes; view logs are coming soon too.
We offer on-prem, and expect a good portion of SMBs to use it over our cloud version.
Good catch on the virtual office! We're actually based in Canada, that's our US company's legal address.
We offer on-prem, and expect a good portion of SMBs to use it over our cloud version.
Good catch on the virtual office! We're actually based in Canada, that's our US company's legal address.
I have several clients that are startups and i usually recommend them JetBrains Datagrip which has yet to disappoint. It also makes it easier to access the databases directly behind a VPN.
Is there a limit to the number of databases a single user can access on a startup license?
The reason i am asking this is that even a small startup can have multiple databases in production. A single license of DataGrip might sound more beneficial in that case.
The reason i am asking this is that even a small startup can have multiple databases in production. A single license of DataGrip might sound more beneficial in that case.
I've been ruminating on this exact problem for months. I'm consulting at a company where we have a lot of non-engineers who own several major processes w/r/t data sources of truth. Engineers need up-to-date programmatic access to that data, and the non-engineers need a way to keep that information accurate.
This is awesome. I was considering building it myself, but it's always a pleasure to see someone else deliver a working product on an idea you've been bouncing around. Good luck, this is a relatively 'simple' product with a huge market.
This is awesome. I was considering building it myself, but it's always a pleasure to see someone else deliver a working product on an idea you've been bouncing around. Good luck, this is a relatively 'simple' product with a huge market.
Glad to hear you like the product! Would love to hear your thoughts after trying it.
TLDR: Giving non-IT users direct edit access to the production DB will most likely break stuff.
I wrote something similar to BaseDash ages ago, I called it dAgent (for database agent). I had it running for many different clients from all sorts of trades (I do custom development). The GUI built itself from reading the DB schema.
My initial motivation was to cut dev time since dAgent would automate the coding of CRUD interfaces. However, the use of dAgent in production ended up being quite limited: maybe only used to edit catalog data (i.e. add a city to the cities table). The reason for this limited usage is no mystery: one can easily break things. In particular non-IT users can break things.
Allow me to use an example. You have a CRM with a customers table. On that table there is a field called status. For that field, dAgent would load a select input using the related table statuses, there was no risk to break integrity. However, in the business logic of this CRM, changing the status of a customer is the result of running a process. That process not only sets the status of a customer to a new value, but also writes a history log, sends email notifications and perhaps triggers an invoicing process.
Now, imagine a non-IT user changing the status field of a customer using a tool such as BaseDash. Now you have a customer in status active who is able to login to your paid SAAS but has never being invoiced.
Many such nightmares can happen when users can directly edit a DB.
For this reason, in production, dAgent features where limited to CRUDing simple catalog tables. It did help, but was not the silver bullet I had hoped for. On the other hand, IT users would never adopt dAgent since the DB engine provided a much more robust and feature-rich admin GUI. I was not in the business of competing with PHPMyAdmin, so I eventually dropped the project.
I wrote something similar to BaseDash ages ago, I called it dAgent (for database agent). I had it running for many different clients from all sorts of trades (I do custom development). The GUI built itself from reading the DB schema.
My initial motivation was to cut dev time since dAgent would automate the coding of CRUD interfaces. However, the use of dAgent in production ended up being quite limited: maybe only used to edit catalog data (i.e. add a city to the cities table). The reason for this limited usage is no mystery: one can easily break things. In particular non-IT users can break things.
Allow me to use an example. You have a CRM with a customers table. On that table there is a field called status. For that field, dAgent would load a select input using the related table statuses, there was no risk to break integrity. However, in the business logic of this CRM, changing the status of a customer is the result of running a process. That process not only sets the status of a customer to a new value, but also writes a history log, sends email notifications and perhaps triggers an invoicing process.
Now, imagine a non-IT user changing the status field of a customer using a tool such as BaseDash. Now you have a customer in status active who is able to login to your paid SAAS but has never being invoiced.
Many such nightmares can happen when users can directly edit a DB.
For this reason, in production, dAgent features where limited to CRUDing simple catalog tables. It did help, but was not the silver bullet I had hoped for. On the other hand, IT users would never adopt dAgent since the DB engine provided a much more robust and feature-rich admin GUI. I was not in the business of competing with PHPMyAdmin, so I eventually dropped the project.
Hey there!
Fellow founder in the same space here. I deeply understand what you are trying to solve cause I am doing the same. I am sure you are trying to differentiate from Jet Admin which is also in YC. ReTool is more mature (also YC). Then there is Forest Admin and Macro is coming out soon.
On top of this, in my early customer validation talks, people ask me if my product is like Metabase or Chartio etc. So yeah it is a crowded space, but I feel this space is huge. Like every business wishes not to invest money in internal tools but they have to. I am still trying to figure out my MVP. I am currently working on complex (JOIN and aggregates) queries without any SQL knowledge. That is what I am going to launch as MVP soon. 2 levels of tables and people really struggle to get out what they want.
An example query I am throwing around is "Show me Orders from Red Shoes". This already means Order, Product and Product Category table. This is a real pain for non-technical people and I believe solving this is becoming critical to encourage and enable every business to be able to ask questions about their Business without needing Engineering.
I am going to go the UI/UX approach to solve this in my MVP and then go for an NLP based approach if things go well. Like if you could type that in a search box and get data, without knowing anything about databases or without needing any Engineering help, that would be real solution to Businesses.
Cheers, and best of luck!
Sumit from dwata.com
Fellow founder in the same space here. I deeply understand what you are trying to solve cause I am doing the same. I am sure you are trying to differentiate from Jet Admin which is also in YC. ReTool is more mature (also YC). Then there is Forest Admin and Macro is coming out soon.
On top of this, in my early customer validation talks, people ask me if my product is like Metabase or Chartio etc. So yeah it is a crowded space, but I feel this space is huge. Like every business wishes not to invest money in internal tools but they have to. I am still trying to figure out my MVP. I am currently working on complex (JOIN and aggregates) queries without any SQL knowledge. That is what I am going to launch as MVP soon. 2 levels of tables and people really struggle to get out what they want.
An example query I am throwing around is "Show me Orders from Red Shoes". This already means Order, Product and Product Category table. This is a real pain for non-technical people and I believe solving this is becoming critical to encourage and enable every business to be able to ask questions about their Business without needing Engineering.
I am going to go the UI/UX approach to solve this in my MVP and then go for an NLP based approach if things go well. Like if you could type that in a search box and get data, without knowing anything about databases or without needing any Engineering help, that would be real solution to Businesses.
Cheers, and best of luck!
Sumit from dwata.com
> I am currently working on complex (JOIN and aggregates) queries without any SQL knowledge
One way to process data without joins and groupy in multiple tables is to use Prosto toolkit: https://github.com/prostodata/prosto It is an alternative to SQL, MapReduce and other classical approaches by radically changing how data is processed
One way to process data without joins and groupy in multiple tables is to use Prosto toolkit: https://github.com/prostodata/prosto It is an alternative to SQL, MapReduce and other classical approaches by radically changing how data is processed
Thanks, I will take a look, although I prefer to stay with relational algebra, Python and R but make them all available through an easier UX. That might be a core selling point for me.
Oh and also adding Actiondesk to the list of YC funded products, I see Jonathan is here in the comments. Hey!
The real power of such kind of tools is determined by its ability to derive (infer) new data from multiple tables, particularly, by linking tables and aggregating data (using these links). Airtable had an interesting approach to this problem (yet, not perfect imho). Here I do not see how can I derive new tables or columns from already existing ones except for using SQL. If BaseDash relies on SQL then the question is what are its USPs which are directly related to data?
We have the ability to join tables along foreign keys in a couple clicks through the UI. Definitely looking into adding aggregated data & computed columns soon!
This is a well known concept sometimes called a SQL editor. There's definitely a need for a great implementation of the concept though. There was a really good one called Wagon years ago that of course got bricked after the team was acquired and I still haven't liked any that I have tried since.
The emphasis on editing production here is a bit odd since there is a lot of value that can be delivered read-only to analysts or to editing development for developers. I have a war story about editing production with one of these tools. Someone used such an editor to edit a MongoDB database value. The ORM schema said it was a float, but it was entered as an int. This somehow broke production for a lot of users.
SQL editors
The emphasis on editing production here is a bit odd since there is a lot of value that can be delivered read-only to analysts or to editing development for developers. I have a war story about editing production with one of these tools. Someone used such an editor to edit a MongoDB database value. The ORM schema said it was a float, but it was entered as an int. This somehow broke production for a lot of users.
SQL editors
* PopSQL
* TeamSQL
* DataGrip
* https://www.beekeeperstudio.io
* [usql](https://github.com/xo/usql/releases)
* [dbcli](http://www.dbcli.com/)We use Postico and are pretty happy with it. It's better for our use cases than e.g. PopSQL.
That being said, we'd drop Postico any day for a smooth editor with 100% Postgres typing support.
That being said, we'd drop Postico any day for a smooth editor with 100% Postgres typing support.
What were your favorite parts of Wagon that haven't been replicated?
This looks really useful! Not sure how it would handle business rules and callbacks, but these days I'm doing much of that directly in the database anyways after years of fighting inconsistencies at the application level (Rails, cough cough).
For admin type dashboards that need customization I've been using Hasura + React Admin (nice replacement for Rails ActiveAdmin). Combine Hasura (automatic GraphQL on top of PostgreSQL) with React Admin (low code CRUD apps) and you can build an entire back office admin suite or form app (API endpoints and admin front end) in a matter of hours.
This adaptor connects react-admin with Hasura: https://github.com/Steams/ra-data-hasura-graphql
For admin type dashboards that need customization I've been using Hasura + React Admin (nice replacement for Rails ActiveAdmin). Combine Hasura (automatic GraphQL on top of PostgreSQL) with React Admin (low code CRUD apps) and you can build an entire back office admin suite or form app (API endpoints and admin front end) in a matter of hours.
This adaptor connects react-admin with Hasura: https://github.com/Steams/ra-data-hasura-graphql
Congrats on the launch. Have wanted something like this for years - most admin tools aren't easy to use like Airtable, and Airtable itself isn't designed to be a backend for your apps. Would love to see a lower-priced tier for just a single user (no collaborators).
Thanks! We'll probably add a cheaper plan for individuals soon. If you're interested, we can set something custom up now. Shoot me an email: [email protected]
> internal tool that lets you edit your production database with the ease of a spreadsheet
I've worked at companies with pgAdmin or something similar that allowed people to edit prod. It was a catastrophe.
As others have said, non-tech people shouldn't have access to prod data, where they may not understand the schema well enough to edit it. Tech people already have GUIs.
Using something like Airtable and syncing it with prod using a thin layer of code is much more viable.
I've worked at companies with pgAdmin or something similar that allowed people to edit prod. It was a catastrophe.
As others have said, non-tech people shouldn't have access to prod data, where they may not understand the schema well enough to edit it. Tech people already have GUIs.
Using something like Airtable and syncing it with prod using a thin layer of code is much more viable.
How does this compare with Prisma Studio? (Prisma framework specifically Prisma 2). Our company is graphql based and uses Prisma Studio as our visual gui for our db
[deleted]
The pricing model is a little strange to me. I would like to see a minimal free tier and then a micro pay-as-you-go query cost than a large set monthly cost.
Great product, solving exact pain point we have right now: non-technical team members glued to Django Admin all day long and waiting days to get much-needed data from engineers, who cannot find the time to write simple views with relevant SQL queries.
I have signed up and started testing your product. Looks great so far. If things check out, there is a good chance we will sign up for real and pay.
Congrats on the launch!
I have signed up and started testing your product. Looks great so far. If things check out, there is a good chance we will sign up for real and pay.
Congrats on the launch!
Congrats and looks great, I like the tracking history/change. If everything is tracked is there a feature to rollback to a previous state? If so, why not also advertise it as a innovative backup + edit solution? That would be be a bigger deal than just the spreadsheet part since people already use DataGrip or TablePlus.
We only track changes made through BaseDash, so we don't have full snapshots of your database to revert to. We'll definitely add a feature to rollback individual edits though.
Max - congrats on the launch! Looks very slick, I'd love to replace AirTable with something more performant. Can I edit the schema yet? Would be great to have a sample database when I login for the first time so I can see the UI in action.
Yes, a sample DB would be amazing! I'd love to try this out, but wouldn't give access to one of our DBs w/o setting up a specific role for BaseDash etc.
Look Good from the description.However i know this is not a very necessary feature but consider adding google login, its easier and quick especially for people who want to test the product before committing.
I under stand this is for internal use, but will there be an on site deployment option?
I would like to give this a test drive against an Oracle cloud database? Possible?
Do I understand correctly that I am supposed to give you write access to my PROD database just so i can edit my production database with the ease of a spreadsheet in a web browser ?
What happens when BaseDash is down ? Do I have to go back to using code again ?
What happens when BaseDash is down ? Do I have to go back to using code again ?
Cool tool, how are you guys different from forestadmin?
could we self host this for DIY/home use?
Nice product, nice UI, nice onboarding experience.
Good job!
Good job!
Any plans for an API?
I was working on a side project a few years ago that required a lot of manual data management. I was using Django Admin which was fine, but wished I could just set up a two-way sync between my SQL database and Airtable (without any crazy Zapier workflows).
After building a quick prototype as an internal tool, I realized that there was a space missing for a product somewhere between an admin panel and a database client. Something with an amazing interface that's usable by both engineers and non-technical users who need to access data within their company (e.g. customer support, operations).
From there, I built BaseDash with a strong focus on expanding upon existing tools I love, with extra care and polish. The resulting product is a polished, opinionated internal tool, with all the functionality most companies need out-of-the-box.
Being a web app, there are some great features that BaseDash enables for cross-functional teams. BaseDash keeps a full edit history of all changes made, makes it super easy to share access to teammates, and enables Google Sheets-like real-time collaboration for editing data.
We currently support most SQL databases (PostgreSQL, MySQL, Redshift, SQL Server, MariaDB), with support for MongoDB and Firestore on the roadmap. We offer a hosted version, or you can host it yourself on-prem.
We're still in early access but happy to invite the Hacker News community to try the product out. We're currently focused on small-to-medium sized software companies, with a combination of engineers and non-technical users. Try it here: https://www.basedash.io and let me know what you think!