BizyDev
3 days ago
If your tool was available on-premise I would be really interested. Since a tool like this is primarily intended, I think, for internal use cases, making it available on-premise should be a priority from my point of view.
Beside this, the tool looks great, congrats for the job, well done!
rnavi
3 days ago
Congrats to visualdb on launch.
If you are looking for free open source version try
https://github.com/nocodb/nocodb
It's fairly simple to setup. Please refer to our readme/docs
Disclaimer: founder here.
replwoacause
2 days ago
Nice, but the AGPL-3.0 license makes this tough to use. Would love to see a MIT alternative if there is one.
ktm5j
3 days ago
Looks awesome! Well done, this might come in handy for folks where I was just hired. Definitely going to keep this in mind.
visualdb
3 days ago
Nocodb is indeed a worthy competitor! If you're interested in how Visual DB is differentiated from Airtable-like products see here: https://visualdb.com/spreadsheet/#airtable
leansensei
3 days ago
I second this, NocoDB is great!
visualdb
3 days ago
Thanks for the feedback. We'll make self-hosted version a high priority.
alek_me
3 days ago
Yes an on premise solution is quite important for place in hired in. To add to this I’ve been doing a lot of looking into products like this and explored nocodb as a use case. Here are some limitations I’ve run into.
1) Granular user roles/permissions. Nocodb has this but it’s a little awkward with different bases. For example it’s hard to see which tables that user is limited to as you create new bases.
2) Forms. The form needs to have flexibility in required fields which nocodb (and not just based on schema) does but it’s missing a key feature. That would be “created by” field which doesn’t work on external database with different bases for different permissions. As in if you have a different base per user group (to have different permission on table access) adding a new record does not populate created by correctly.
3) relational data. The goal of these products is for non-technical people to use these and none have the option of clicking into the relation to bring up that record on its table. As in all you see is the description/id of the relational record.
4) at some point you want to possibly use the database for user management. Because you may want to write an internal tooling that scans a qr code or something or the form is client based. But then you have users that may live on a different database interacting with your main database. And then you would need to match the users with what they view and what they can create.
Essentially what I found is that with nocodb is that it is good for viewing data but to add data I need to create forms. But then nocodb lacks in “dashboard” statistics and graphs
Sorry if this is not clearly explained. I’m on holiday and tired rn.
visualdb
3 days ago
Regarding permissions, I think we meet your requirements. End users do not have permission to tables directly, they can only enter data through forms and sheets.
Regarding "created by", do you mean a field that is automatically set, based on who created the record? That's on our todo list.
Regarding relational data, we meet your requirements. Any time there is a foreign key, we display a "..." button which shows up with records from the foreign table you can select the row you want. This is fairly sophisticated... you can display all records from the foreign table (default), our you can have a query, and you can even have cascading dropdowns (for example you select Region in the first dropdown, then it shows Cities in that region in the next dropdown and so on), then matching rows are shown.
Regarding user management we store users and permissions separately from databases, and the permissions you applies to all databases in the application. Permissions are set at the application level and you can create a different application (with connections to same databases if needed) if you want different permissions.
rnavi
3 days ago
Thank you for taking time out of your holiday and writing this.
2) If you create the tables from noco interface you get those fields else not as these fields are abstracted fields on top of your DB fields. 3) not sure what you mean here - noco is known for abstracting these IDs away and are hidden as system fields (see field menu). The role of lookup etc is what you need.
1 & 4 are feature requests pending on us.
sixtyj
3 days ago
It looks nice, indeed. Upvote for on-premise version.