Show HN: Base, an SQLite database editor for macOS

> Create and modify tables with ease using Base's visual table editor. No need to write complex CREATE or ALTER statements.

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?

You call do everything with the sqlite cli tool, but GUIs are very convenient to explore and play with the databases.

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.

Potentially about anyone who used Access without the forms interfaces... While I'm not the biggest fan, I know a lot of people who prefer a visual editor for table schema creation. They'll use SQL Management Studio, or whatever equivalent with other DBMS and edit that way instead of DB specific queries... For example, re-ordering fields is destructive in a lot of DBMS and the queries get painful, a visual editor eases this burden.

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).

A lot of people use it as a step up from Excel.

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.

I know researchers (think field biology) who need to enter data into SQLite databases with bespoke apps but on occasion it’s imperative to edit or search the database directly. I’ve helped them do that on some butt-ugly app they had installed whose name escapes me. Looking at Base, my immediate thought was to buy it for them.

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.

>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 QStudio supports right click query csv,txt,parquet via duckdb. It also supports more exotic data sources like rest apis by placing the data into a temp table. I called it babeldb https://www.timestored.com/qstudio/csv-file-viewer

Visual browsers are very nice for exploring and pulling data out of databases that aren’t under your control, such as those used by apps. For example, first-party Apple apps nearly all use SQLite locally, and so with a browser you can peer into and hack on their data storage.

For quite some projects, before coding anything I tested out if my logic is sane by hand-crafting a prototyle sqlite db. Really helps visualizing my thoughts how to layout the data before I start a project, work with an ORM etc.

But then why would you:

> Create and modify tables with ease using Base's visual table editor. No need to write complex CREATE or ALTER statements.

> And thus these kind of statements happen within an application.

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.

Not using it this way, but wanting to: a friend of mine is working on a TTRPG. He has items, powers, other things to track - and right now it's in a mess of a Word document.

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.

Same reason why would you build a form in VB or Xcode rather than coding it all out.

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.

You're not sure of the target audience for an ad hoc SQL query analyzer? You've never needed to figure out a complex join for your application without trying to do it from the command line client?

https://datasette.io is a similar tool for journalists to disseminate and share data

I'm a programmer and I barely understand how to use SQL so this would be useful for me