Can i put it inside a docker container alongside my pg container and serve it under a path like “/dbadmin” with password protection? That’s my current workflow with pgadmin.
https://github.com/Brayden/starbasedb/blob/main/src/studio/i...
41–50 of 153 posts
Can i put it inside a docker container alongside my pg container and serve it under a path like “/dbadmin” with password protection? That’s my current workflow with pgadmin.
https://github.com/Brayden/starbasedb/blob/main/src/studio/i...
For years I've wondered why a general purpose, high quality, good UX, browser based DB browser has not existed. I've implemented 3 such (not general-purpose) browsers in my career. But I'd be really happy to stop doing that and use this instead. I would love to see a Firestore driver implemented (maybe I'll take a crack at it some day), as I'm stuck in GCP land for the time being.
Biggest limitation right now is its lack of support for vector style databases like Lance, qdrant, etc.
I downloaded it, fired it up locally, was presented with a login screen , closed it, and uninstalled it. Sorry, but I don't log into local software.
I saw that it was AGPL licensed, which was odd to me for something that's supposed to be a client. I don't like the AGPL license because of how overbearing it is, I avoid downloading AGPL'd software, unless its a pure compiled binary. I am probably a little too strict about software licenses, but I rather always have the freedom to keep any forks to myself, don't force me to share code for my one-off project.
Earlier quoted context omitted.
Are there comparisons to related projects somewhere? E.g. I've use DBeaver before. Is there some reason I should try Outerbase next time?
I put together this in related to our cloud offering, it's still somewhat relevant for Outerbase Studio even though some features are different: https://www.outerbase.com/blog/the-5-best-database-managemen... Our goal is to make data accessible through good user experiences and focus. Whether that is being able to spin up a local database directly from the app, or simply making the query experience as intuitive as po…
Is the long term intent eventually to have parity between the open source desktop app and the cloud version (at least in terms of database type support)?
For years I've wondered why a general purpose, high quality, good UX, browser based DB browser has not existed. I've implemented 3 such (not general-purpose) browsers in my career. But I'd be really happy to stop doing that and use this instead. I would love to see a Firestore driver implemented (maybe I'll take a crack at it some day), as I'm stuck in GCP land for the time being.
Because it does exist, but it's not free. Jetbrains Datagrip has been around for a decade and has connectors for most database archetypes (mongo, sql, redis, duckdb, etc). Biggest limitation right now is its lack of support for vector style databases like Lance, qdrant, etc.
Earlier quoted context omitted.
Because it does exist, but it's not free. Jetbrains Datagrip has been around for a decade and has connectors for most database archetypes (mongo, sql, redis, duckdb, etc). Biggest limitation right now is its lack of support for vector style databases like Lance, qdrant, etc.
> Browser based
For years I've wondered why a general purpose, high quality, good UX, browser based DB browser has not existed. I've implemented 3 such (not general-purpose) browsers in my career. But I'd be really happy to stop doing that and use this instead. I would love to see a Firestore driver implemented (maybe I'll take a crack at it some day), as I'm stuck in GCP land for the time being.
Because it does exist, but it's not free. Jetbrains Datagrip has been around for a decade and has connectors for most database archetypes (mongo, sql, redis, duckdb, etc). Biggest limitation right now is its lack of support for vector style databases like Lance, qdrant, etc.
Not only that, but the SQL support works for embedded strings in programs written in other languages such as Go. So it knows that some statement conn.Exec("SELECT ...") is SQL and syntax-highlights it, performs schema validation and autocompletion inside the string literal. Not only that, but you can open the string literal as a separate editor and edit it, including doing things like "reformat", which was an unexpected delight when I discovered it.
It's this kind of "feature stacking", which features working organically with each other, that makes Jetbrains IDEs so damn good.
But the basic database tools are also superb. Its table view is really fast. It has syntax highlighting (e.g. if a column value is JSON), live editing (including the ability to open a column value as an editor, in which case you get all the usual syntax tools), and even graph rendering with support for multiple data series and grouping in a single graph.
There is also excellent support for exporting data. You can mark a bunch of result rows and copy them as CSV or as SQL INSERT statements, or you can save the entire result to a file. This is how I often export data from BigQuery, as it's much more convenient than Google's own tooling (the web UI is particularly bad, requiring that you export the query result to a GCS bucket first).
These database UIs aren't technically difficult to do. But somehow nobody else seems capable. The closest I can think of is Microsoft's tooling around SQL Server, which is pretty slick, albeit MSSQL-specific. I often wonder how Jetbrains, which is a pretty small company, can be so effective and produce such an incredibly feature-rich product portfolio.
Earlier quoted context omitted.
> Browser based
Missed that - I am a little unclear how being wrapped in electron as an app is necessarily an advantage - I guess it could be valuable if it were pulled out electron, and you could host it as a service.
It's mostly just a nicely bundled way to run it if you aren't very technical but still want a easy to use database client.
You can also run commands like this to connect to your database if you want:
npx @outerbase/studio \ --port=5000 \ --user=admin --pass=123 \ mysql://root:123@localhost:3306/chinook