[HN Gopher] SQLite File Format Viewer
       ___________________________________________________________________
        
       SQLite File Format Viewer
        
       Author : ilumanty
       Score  : 130 points
       Date   : 2025-04-14 14:55 UTC (8 hours ago)
        
 (HTM) web link (sqlite-internal.pages.dev)
 (TXT) w3m dump (sqlite-internal.pages.dev)
        
       | mubou wrote:
       | This is really cool.
        
       | NathanFlurry wrote:
       | I've been enjoying watching you build this on X - nice work.
        
         | invisal wrote:
         | Thanks so much :)
        
       | throw0101d wrote:
       | Meta: always found it interesting that _.dev_ was allowed to be a
       | TLD:
       | 
       | * https://en.wikipedia.org/wiki/.dev
       | 
       | More on-topic: another online option:
       | 
       | * https://sqliteviewer.app
       | 
       | * https://inloop.github.io/sqlite-viewer/
       | 
       | Local app:
       | 
       | * https://sqlitebrowser.org
        
         | invisal wrote:
         | This is a different tool--SQLite File Format Viewer is made for
         | anyone interested in exploring the internal structure of
         | SQLite.
        
         | pppone wrote:
         | I really like the VS Code extension for sqliteview.app - [0].
         | It also offers an edit feature for a reasonable price, in my
         | opinion. I'm curious if there are any competing editor
         | alternatives.
         | 
         | [0] - https://vscode.sqliteviewer.app/
        
           | Kwpolska wrote:
           | The only reasonable price for editing a SQLite database is
           | $0.
        
             | lupusreal wrote:
             | Or $2000 for a perpetual license to the Sqlite Encryption
             | Extension, if the database is encrypted ;)
             | 
             | Honestly not a bad price if you're building it into a real
             | product. Steep for hobbyists though.
        
       | latexr wrote:
       | I especially like that it provides a sample database. Would be
       | nice it were downloadable as a file, so we could explore it with
       | our own tools as well and get a better feeling for how the tool
       | works.
        
         | TheRealPomax wrote:
         | https://github.com/invisal/sqlite-internal/tree/main/public, or
         | just download it by copying the URL from your network tab when
         | you load it.
        
       | graemep wrote:
       | Very cool.
       | 
       | It would be nice if it tied the format in a bit more to the
       | schema and data being shown, but that is a very minor gripe given
       | how nice a tool this is.
        
       | NoSalt wrote:
       | Really nice, looks great!
       | 
       | However, I am not a fan of uploading databases to "strange" sites
       | on the internet, so I will probably never use this.
        
         | brulard wrote:
         | There is a github link so you can run it yourself
        
         | jchw wrote:
         | AFAICT it's purely frontend, there is no uploading. Aside from
         | running it yourself, another thing you can do is go into
         | devtools and set the network throttling to "offline". (Note
         | that this is not fool-proof, but it does prevent new
         | connections from being established.)
        
         | olejorgenb wrote:
         | You can probably run it yourself:
         | https://github.com/invisal/sqlite-internal
        
         | chungy wrote:
         | It's hard to know whether anything is actually uploaded, but
         | thankfully SQLite databases are plentiful that don't contain
         | sensitive data (and this, also, is why there is a sample
         | database included).
         | 
         | I loaded up my Star Trek database into the program to toy with:
         | https://chiselapp.com/user/chungy/repository/startrek-db/uvl...
        
         | senkora wrote:
         | I wish that we had a browser version of "pledge" that would:
         | 
         | 1. Permanently restrict the browser tab from accessing the
         | network.
         | 
         | 2. Show an indication of this in the browser UI outside of the
         | content area.
         | 
         | It would be perfect for this kind of app.
        
           | runjake wrote:
           | In this case, itt's easier to just run it locally:
           | https://github.com/invisal/sqlite-internal
           | 
           | But you can get sort of what you want by:
           | 
           | 1. Loading a site.
           | 
           | 2. Go into the Web Dev Tools.
           | 
           | 3. Select the Network tab.
           | 
           | 4. Click on the "No Throttling" dropdown and check "Offline".
           | 
           | 5. You should now see a yellow warning icon in your Network
           | tab and it should prevent all network access. If you reload
           | the tab you should get the "No Internet Connection" error
           | page.
        
             | creatonez wrote:
             | What a fantastic method, I'm gonna start using this for all
             | the random tools I upload data to expecting they are fully
             | clientside.
        
       | jchw wrote:
       | This really would've come in handy when I was debugging my own
       | SQLite parser a couple weeks ago.
       | 
       | One thing that initially confused me was how exactly the pages
       | worked w.r.t. the first page on disk... I misunderstood the
       | SQLite documentation in different ways, but it's really rather
       | simple: the very first page is just treated as containing the
       | file header in it, and it pushes down the rest of the data,
       | making the page shorter than the other pages. You can see that
       | illustrated clearly if you click into the first page of a
       | database using this tool: the database header comes first, then
       | the page header.
       | 
       | This tool will undoubtedly come in handy for anyone who has a
       | reason to be dealing with SQLite data structures directly for
       | whatever reason, especially since the SQLite documentation is a
       | bit terse at times.
        
         | hinkley wrote:
         | I really want a data format that is effectively binary JSON.
         | What is the subset of all of the features of SQLite that makes
         | either a read-only or an updatable data set that is compact.
         | But better searchability than a streaming parser.
        
           | jchw wrote:
           | If you want to maintain the properties that SQLite has for
           | read use cases, you'll need to replicate a couple of
           | features. At the very least, you'll probably want the format
           | to still be page-based with a BTree structure. You really
           | could get away with just using the SQLite format if you
           | didn't mind the weirdness; a functional SQLite parser that
           | can read tables would not be a significant amount of code. I
           | think, though, that if you want to read the schema as SQLite
           | understands it, you'd need to interpret the CREATE TABLE
           | syntax, which would make it a bit more complex for sure.
           | Otherwise, you can read tables and columns themselves
           | relatively easily, and the values are all stringified.
        
             | hinkley wrote:
             | Yeah if I wasn't clear I'm talking about a minimal file
             | that SQLite can still open read only without errors, not a
             | third party implementation. Though there might be a few
             | tweaks that would allow SQLite to be a bit more lenient.
             | For instance missing metadata that can be assumed. Maybe b
             | tree nodes exceeding the usual load factor.
        
           | Retr0id wrote:
           | sqlite itself supports a binary encoding of JSON:
           | https://sqlite.org/jsonb.html
        
             | hinkley wrote:
             | When I said binary JSON I didn't mean literal JSON. I meant
             | "common denominator interchange format". It's too chatty by
             | far and has dismal performance for queries. So you're
             | better off asking a specific question and getting a larger
             | document that could answer many questions that you do t yet
             | have. For CDNs things like this matter a lot.
        
           | cwmma wrote:
           | Parquet or some other column oriented data format is probably
           | closest to what you want without getting into indexing your
           | flat files or similar
        
       ___________________________________________________________________
       (page generated 2025-04-14 23:00 UTC)