Product Launch
anonymous
693 points
181 comments
Posted5 months agoActive4 months ago
Base
menial.co.uklaunchedweb_appdevelopers
Key Features
alters SQLite tablesdetailed display of column constraintsattaches databases
Tech Stack
SQLite
Key Features
Tech Stack
EDIT: Very minor nitpick but noticed I changed my icon to dark, but not taking effect. Still using light icon.
I'd say the main benefit is that it's tailored only to SQLite's features.
You don't have to tweak a UI tailored for remote connections to work with local files. You don't need to have extra sections dedicated to user management or stored procedures which are inactive. I guess I'm saying that in this case less is more!
People who care about their tools. If I have to stare at it all day, being pleasant on the eyes is a feature. If every time I grab my tool I think “urk, this is so ugly”, it affects my flow.
- It fits with the system better and behaves more like other macOS apps
- I believe Base has better create/alter table support
However Base doesn’t (currently) have support for SQLCipher.
As much as visually fitting in is important, behavior is perhaps bigger. Anybody who’s working on the Mac port of a cross platform toolkit would do well to replicate those little bits.
I don't think Base is at all and only supports macOS
While the database stuff works on Linux and Windows, building UIs for the 3 platforms is very different, unless you use some cross platform wrapper layer. Which isn't the purpose of this one. You might want sqlitebrowser[1] if you're looking for something like that.
This makes for a much nicer app for mac users, even if it does cut your potential audience.
Think like MySql Workbench but for multiple users, that would be incredible
For those who’ve not seen it already, there’s a good guide on when to use SQLite here: https://sqlite.org/whentouse.html
Is that another way of saying you don't want to make MS Access?
I still use Access quite a bit and I think it's pretty great. It's too bad that nothing like that exists for modern databases.
It's unlikely that I'll add a form builder or report generator to the app. I don't want it to grow until it can send email.
Many years ago, there was a project that tried to do just that using Tcl/Tk, which seems like a fine choice - Tcl is very simple and easy to understand even for on-programmers while its deficiencies aren't really important in this niche, and Tk is one of the easiest UI frameworks around to use. Unfortunately it petered out and I can't even remember the name anymore...
I've been using TablePlus a lot, but there are some SQLite-specific features I'd really like to have in an app:
- Foreign keys enabled by default, so I don't have to remember to enable that in every session.
- Support for loading extensions automatically. I'm using sqlite-vec for example. Right now, browsing virtual tables for that just doesn't show that much, and executing a query just results in "no such module: vec0"
I'll keep an eye on the project. :-)
Auto-enabling foreign keys absolutely should be an option. I'll make a note of it.
I don't know about auto-loading extensions though. Will have a look. That might not mix well with the App Store rules and I'm reluctant to let the direct/app store versions drift apart in terms of features.
I was happy to see that FTS5 was always enabled as a compile-time option.
I'm trying to understand who your target audience is? Normally, I think of SQLite as something that only a programmer would use. (And thus these kind of statements happen within an application.)
What kind of use cases are you handling where someone is manually creating / changing a schema?
> Import data from CSV and SQL dump files. Export your results to SQL, delimited text, JSON, and Excel formats.
IE, who's using SQLite in this way, and what are they using it for?
As to importing/exporting data (csv, etc), You can't exactly run queries against a CSV generally (I mean you can with JET/ODBC, but still)... it's a chore.
To another point, I often feel that sqlite is a great backup format for data, it's portable, you can query directly, etc. I kind of wished that Azure Data Studio (now discontinued) had directly supported loading CSV/TXT etc into an in-memory or temp db for queries and portability similar to mentioned between various data sources (sqlite, mssql, pgsql, etc).
> Create and modify tables with ease using Base's visual table editor. No need to write complex CREATE or ALTER statements.
Even if you need the actual instantiated schema to pass to SQLite in your source code, that's easy to obtain after-the-fact if this app doesn't output it directly, using `.schema` from the SQLite CLI.
I have regularly used sqlitebrowser. You can even get create table statements corresponding to tables you have drafted with it, and you can copy-paste these statements in your code. Or build and test a sql statement incrementally, and paste it in your code when you are happy.
Or even to plain browse data, explore database from other tools, etc. There are a lot of occasions where such a tool can be convenient.
Additionally, while I know my way around and even enjoy the command-line, on occasion I bump into some app’s SQLite database that I want to explore. I can see myself using a GUI for those instances to help me find the data I’m looking for faster.
It would be so much better if he could store these things in SQL - for non developers, they often use Excel, when a SQL DB is the correct solution, just because they can't figure out SQL at all. A visual editor/manager is perfect for them - create a table with columns, enter data, later integrate with other tools that can pull it out.
Who made that rule? Most database tools I have used do this. I can go into SQLite's command interface and do it. It's not limited to the application.
Not all of us want to write code for everything. Sometimes when I'm developing an app or an idea, the last thing I want to do is keep messing with cruft I don't have to. It's a waste of time to write yet another alter/create/etc script. I just click and change it. That's it, and I move on. I don't care until my design is done to export/create the creation/alter scripts, if I even need them, because I can ship a fully set up DB file with the app, I don't actually have to have scripts for that stuff. Sure, later I may need to on an update, but when rapidly prototyping I'd rather just have the quickest way to deal with it. Else, the argument becomes "Why not just use the SQLite terminal interface instead of a graphical tool?" or "Why would you create or rename a directory using Finder rather than a shell script to do it?"
> IE, who's using SQLite in this way, and what are they using it for?
Anyone that wants to do such things? I just recently wrote an app that runs in a browser using only javascript, but in the end I wanted the data and it exports it to JSON so I can load it into another app. I haven't gotten around to integrating these (and I probably won't) as the app is a pure browser application, but the other is a tool for creating TTML2 documents, and I need that data. So, I can easily import that. It's not a commercial thing, it's my own. So, I don't want to merge the two. I don't mind the step. This sort of thing is good. What is wrong with the ability to do so? PostgreSQL can do it. You don't believe it could be useful to export your data so that someone that isn't using SQLite can view it? Dumping a table for viewing in Excel is so common that I don't really understand why you're asking.
There are literally billions of devices using SQLite. And within those devices, countless applications are using the thing. Do you believe it has a limited set of use cases? Heck no.
Your questions seem like bait and I bit.
I’ve got quite a few scientists using it for data analysis, a whole bunch of people importing sales data for querying.
A good number of folks never write any SQL and just use the GUI to sort/filter data.
I’ve also heard from people who use Base to design a schema and then export the SQL into their codebase.
EDIT: I should add that Base does nothing that that the command line tool can't. But it does offer more convenience, particularly for those who might be less comfortable writing SQL.
Jetbrains products realize that these binary values are UUIDs and let me edit them easily.
This is a bit of a shift, but the numbers aren't really stable yet so it's hard to tell if it'll stay there.
Both MariaDB and SQL Server have dedicated data types for UUIDs, and they sort in an unexpected order if you're unfamiliar with the structure of a UUID or the endianness of certain portions of it. Oracle assumes it's going to be binary, but the generating function SYS_GUID() has some endianness issues you can run into. Meanwhile, PostgreSQL kist sorts them like a string!
Similarly, if you're using .Net to generate a native GUID type and passing that through your RDBMS provider, it may arrive and be stored differently due to that endianness problem.
Expecting that every SQLite database is going to be storing UUIDs in an identical manner seems insane to me.
It's the fact that, as the Base author, you don't really know how a given application might present a 16-byte binary version of a UUID to the database. If you don't know that, how can you reverse it to display the correct string representation? There are complications with byte groups potentially being in different places, and even the potential of mixed byte ordering.
How can Base make a 16-byte binary format that display both a GUID stored from a .Net application from person A, and also a UUID from a Python application from person B, and have the string representation be accurate in both cases? I don't think you can.
A binary blob of 7-bit-clean ASCII still fits within a binary blob.
Too bad this is mac only. I mean, im a mac user (among other things) but i don't want to depend on platform specific tooling.
The “thick” tool will always be more efficient than a browser-based tool. It will always be more native and integrate with the OS better. It will perform better (though that may not always be visible).
Yes I am seriously asking. The web is the worst application platform ever created, despite being maybe the only true cross-platform platform.
> The web is the worst application platform ever created
That's an extreme position. Today no one is making native Windows apps because the web has defeated native apps on Windows.
the web has defeated native apps on windows because native apps on windows are dead all on their own. not because browser applications are better, because they aren't, but because Microsoft drove those applications into the ground with clear intent.
I don't think people realize this, but browsers are SLOW. Not just a little, A LOT. Native code will always be faster, will help extend battery life, and are far simpler to write, to understand, and to support. On top of that, there are entire classes of security vulnerabilities that simply don't apply if you aren't a browser application.
Browser applications ARE convenient, though. But we previously solved that on the desktop and people forgot about it, so now it apparently is IMPOSSIBLE to click a single link and have a running application locally, despite it being easily done in the recent past. That can never happen again, apparently.
I don't expect the HN crowd to understand this. I expect the HN crowd to NOT understand this, as getting your silly startup funded requires that you not understand this simple concept. There aren't any startups making desktop applications.
I do expect technical people to understand why browser applications are bad compared to equivalently-featured native applications. But it's a faux-pas to say so anyway, because it might impact how many people give you money in the future or how much they give. People gladly trade money in exchange for ignoring inconvenient problems all day long, and without a second thought, too. Somehow, I find that anathema, despite being in the position to accept such offers several times throughout my career.
I am really starting to come around to the idea that everyone that works at Meta, Google, or at any startup writing a web application knowing that it is easier to write despite all of the horrible tradeoffs has weak moral fiber. I think those people are sellouts. I think those people know that they are creating tools that die when the company dies, require a continuous internet connection despite knowing that a constant internet connection is not feasible for a large portion of people, and create software that uses far more energy than it should despite knowing that native code is far more efficient.
Being an engineer means you face the problems you have, and you do not make up problems in order to create a business opportunity. But people forget all about their scruples when money stares them in the face.
The desktop environments that we have are constructs, and as such they can be made better. They can be remade. There can be a good cross platform environment that is easy to develop for, is relatively efficient, performant, consistent, and which allows for offline use if we just want to create that. But the money is too good if you want to ignore that problem, I guess.
In my opinion, native macOS apps used to be awesome, but when Apple switched to flat UI they removed one of the chief attractions of native apps: better look & feel.
you are pointing at a web application that is slower than a native one, and which uses more energy than a native application.
My main complaint is that everyone is avoiding the real problems because they fear that they may be too large to tackle. so, they make up other problems and solve those because they guess that solving those problems is easier. So they write web applications and mobile applications which are larger than entire operating systems like Windows XP or Windows 2000.
So hyperlinks were good but the rest was a bad design. An HTML viewer and Javascript interpreter would have just been one possible app to run in the browser.
It is a shame that, to this day, the browser can't easily handle running arbitrary applications. You're still effectively locked into JS/HTML.
We’ve literally chosen the worst version of the web possible. Intentionally.
Right now innovation moves at a slow pace the web nobody seems to realize the what-if. The W3C announces some incremental improvement to JS feature and everyone gets excited. It just reminds me that all we realistically have is JS.
There are so many hacks on top of hacks. Typescript compiles to JS because, well, you only have JS. So many attempts at compile-to-JS languages. There are dozens of problems that should not exist.
Meanwhile in the native world, you have huge a diversity of programming languages and tooling. No committee is needed for each language to experiment with new features.
The unfortunate part is that the envisioned browser would have been far simpler to implement and more extensible than the mess we have now.
Of course, there’s a balance to be struck to support users, but macOS update uptake is usually pretty fast.
Since Tahoe is likely to be released in the next month or so, I judged it better to start with Sequoia and keep it supported rather than start with Sonoma and risk needing to drop it shortly after launch.
Now if you did that and used it on your 3 versions out of date macOS, then an update came that only worked on current-2, you'd be pissed.
Mostly only software with subscriptions can afford to keep supporting multiple versions.
1. If you're a developer, then you're probably using sqlite to store data and having a GUI for checking/modifying the database is probably handy.
2. Most application by other developers (even massive companies) use sqlite to store data under the hood even if the file doesn't appear to be named `.sqlite`. So if you want to tweak certain settings that aren't exposed to the end user, then you can use this to do that in a more user friendly way rather than crack out a command line tool for sqlite changes.
- Storing results for scientific research
- Local analysis of data exported from server-based databases
- Experimenting with database designs before exporting SQL to codebases
- Maintaining relational data where a website or app are not needed (eg. tutors keeping client records)
- Recovering data from databases used by other products (eg. phone backups, discontinued apps)Will be upgrading in the future, congratulations on the launch!
And worse, because they're paid you don't even get the source code to fix issues yourself :/
But... expensive? Really? A one-off cost (not a subscription, mind) for a tool that might make an expensive developer/data person even marginally more productive? You have to be kidding. It blows my mind how much developers, who of all users should be the ones who appreciate how much work goes into something like this, complain so often about the cost of basic tools.
There’s a ton of work that’s OSS. There’s also a ton of work that’s not.
This is a tool that I’d happily pay double the amount that they’re asking if it was OSS. I also regularly fund OSS maintainers.
Heck I’d even be fine with a closed source by default, but pay to get source code access too.
As to pricing, I need to be able to financially justify the time spent working on the app, and the price is one that I hope will let me do that.
Or are you worried about people stealing and making pirated copies?
I know you could make the argument “the right license wouldn’t allow that”, but that would only be enforced if you follow up through the courts, perhaps internationally. I just can’t be doing with the hassle unfortunately.
this is on par with AAA games that have tons of creative assets, art, music, thousands of people work on them for years.. and here is a utility that did not even invent SQLite itself, not a dollar goes to SQLite creators either. rather a light wrapper over standard UI build by Apple - SwiftUI. what is the marginal contribution from creator here for this price? what a ripoff
that movie has tons of AAA-grade creatives, AAA-grade actors, tens of thousands of people work, brand new music, licenced music, photos, drawings, videos, animations and motion graphics, 3D assets, pictures, photos, whole buildings and set built for this, that borderline tiny real towns. LotR had to develop brand new state-of-the-art VFX rendering tech, which is often the case with such projects.
VFX for say "fake" UI Iron Man suit, had to write tons of code to make it work. amount of work those movies and games take in creatives (very often it is just code) is unbelievable.
now, with this utility app. what did it produce? not even close.
but that does not mean it is "worth it". as in, marginal contribution and work people did to make it happen. banana duck-taped to a wall, same story.
same story here. marginal contribution is too low compared to price
Nobody else is working on the GUI side. I can tell because I'm working on the ibtool replacement and none of the relevant constants or required code exists anywhere on Google. It's a complete reverse engineering from scratch for anything added in the last decade.
I’m curious (as a solo dev) if there’s a market for such a product.
I believe the macOS app OmniGraffle can do this, like Microsoft Visio on Windows.
I currently have a copy of Database Designer installed on an Android tablet, it's quite effective for my simple projects.
https://play.google.com/store/apps/details?id=com.klim.dbdes...
Database Designer developer says the app is "free forever", which is nice. App stores note in-app purchases; these are voluntary donations like "Buy Me a Coffee".
The app also has some brief demo videos that are linked as online help.
I don't think Omnigraffle offers direct synchronization for editing database structures between its diagrams and SQL code.
I'm glad I see this now. I guess it's time to switch.
Still can't believe this was created 15 years ago...
I like these kinds of things though. Minimal purpose built tools.
Copy pastes, duplicate rows, sorting and filtering. Sadly postico does not do SQLite.
But for SQLite as native app, there is no better than Base.
Look forward to the upgrade thank you.
Edit: thanks for row edit, that's great. What about duplicating rows or copying between tables of the same structure?
As an aside, feature bloat is a massive problem with macOS database tools.
I'd happily pay for something basic, native, and pretty like Sequel Ace†, but all of the other options are Swiss Army knives for power users who need to tweak every little thing. I just want to do some queries.
† I'd pay for Sequel Ace, too, if it didn't crash every time I close a tab.
21 more comments available on Hacker News
Not affiliated with Hacker News or Y Combinator. We simply enrich the public API with analytics.