Live data from Hacker News

SQLite's File Format

sqlite.org

21–30 of 86 posts

Re: SQLite's File Format

#21
post #2

I certainly do appreciate that the file format internals are so well documented here. It really reveals a lot of information about the inner workings of sqlite itself. I highly recommend reading it; I actually saved a copy for a rainy day sometime and it was very insightful and absolutely influenced some design decisions using sqlite in the future.

The format itself is a U.S. federal standard, and cannot be changed. That has advantages and drawbacks.

https://www.sqlite.org/locrsf.html

Re: SQLite's File Format

#22
post #18

Any recommendations from HN for a write-once (literally once), data storage format that's suitable for network storage? sqlite docs recommend avoiding using it on network storage, though from what I can gather, it's less of an issue if you're truly only doing reads (meaning I could create it locally and then copy it to network storage). Apache Parquet seems promising, and it seems to support indexing now which is an…

SQLite works fine over read-only NFS, in my experience. Just only work on an immutable copy and restart your application if ever changing it. If your application is short lived and can only ever see an immutable copy on the path, then it is a great solution.

Re: SQLite's File Format

#23

SQLite is a great example of a single factor mattering more than everything else combined. A database contained in a single file is such a good idea that it outweighs a poorly designed storage layer, poorly designed column formats, and a terrible SQL implementation. If craftsmanship is measured by the long tail of good choices that give something a polished and pristine feel, then SQLite was built with none of it. An…

> poorly designed storage layer, poorly designed column formats, and a terrible SQL implementation

Is this opinion shared by others?

Re: SQLite's File Format

#24
post #17

> The database page size in bytes. Must be a power of two between 512 and 32768 inclusive, or the value 1 representing a page size of 65536. What an odd design choice. Why not just have the value be the base 2 logarithm of the page size, i.e. a value between 9 and 16?

If I had to guess this field was specified before page sizes of 65536 were supported. And at that point using the value 1 for page sizes of 65536 made the most sense.

Re: SQLite's File Format

#25

SQLite is a great example of a single factor mattering more than everything else combined. A database contained in a single file is such a good idea that it outweighs a poorly designed storage layer, poorly designed column formats, and a terrible SQL implementation. If craftsmanship is measured by the long tail of good choices that give something a polished and pristine feel, then SQLite was built with none of it. An…

It was designed to be a DB for Tcl at a time when that language didn't have typed objects. Its SQL implementation reflects that. Where are the grand Python, or Perl, or JS DBs?

Re: SQLite's File Format

#26
post #21
post #2

I certainly do appreciate that the file format internals are so well documented here. It really reveals a lot of information about the inner workings of sqlite itself. I highly recommend reading it; I actually saved a copy for a rainy day sometime and it was very insightful and absolutely influenced some design decisions using sqlite in the future.

The format itself is a U.S. federal standard, and cannot be changed. That has advantages and drawbacks. https://www.sqlite.org/locrsf.html

I assume the SQLite team could increment the version to 4 if they really needed to, and leave the LOC to update (or not) their recommendation, which specifies version 3.

Re: SQLite's File Format

#27
post #23

SQLite is a great example of a single factor mattering more than everything else combined. A database contained in a single file is such a good idea that it outweighs a poorly designed storage layer, poorly designed column formats, and a terrible SQL implementation. If craftsmanship is measured by the long tail of good choices that give something a polished and pristine feel, then SQLite was built with none of it. An…

> poorly designed storage layer, poorly designed column formats, and a terrible SQL implementation Is this opinion shared by others?

Dr. Hipp has said several times that nobody expected a weakly-typed database to achieve the pervasiveness that is observed with SQLite.

At the same time, strict tables address some of the concern of those coming from conventional databases.

Dates and times are a core problem to SQLite not seen elsewhere as far as I know, but this does evade UTC and constantly shifting regional time. My OS gets timezone updates every few months, and avoiding that had foresight.

Default conformance with Postel's Law is SQLite's stance, and it does seem to work with the ANSI standard.

Re: SQLite's File Format

#28
post #21

Earlier quoted context omitted.

The format itself is a U.S. federal standard, and cannot be changed. That has advantages and drawbacks. https://www.sqlite.org/locrsf.html

I assume the SQLite team could increment the version to 4 if they really needed to, and leave the LOC to update (or not) their recommendation, which specifies version 3.

Very true.

However, a significant fraction of the current installed base would not upgrade, requiring new feature development for both versions.

The test harness would also need implementations for both versions.

Then the DO-178B status would would need maintenance for both.

That introduces significant complexity.

Re: SQLite's File Format

#29
post #23

SQLite is a great example of a single factor mattering more than everything else combined. A database contained in a single file is such a good idea that it outweighs a poorly designed storage layer, poorly designed column formats, and a terrible SQL implementation. If craftsmanship is measured by the long tail of good choices that give something a polished and pristine feel, then SQLite was built with none of it. An…

> poorly designed storage layer, poorly designed column formats, and a terrible SQL implementation Is this opinion shared by others?

I think it's one of the reasons DuckDB has seen the popularity that it has.

Re: SQLite's File Format

#30
post #17

> The database page size in bytes. Must be a power of two between 512 and 32768 inclusive, or the value 1 representing a page size of 65536. What an odd design choice. Why not just have the value be the base 2 logarithm of the page size, i.e. a value between 9 and 16?

There exists hardware with non-power-of-two disk sector sizes. Although sqlite's implementation requires powers-of-two today, a future implementation could conceivably not. Representing 64k was presumably an afterthought.

https://eki.moe/posts/using-520-byte-sector-disks/

Post reply on HN