Hacker News Reader

Comment by de_aztec | Hacker News Reader

Since it’s not clear from the title: embedded here does not mean sqlite-inside-your-app but small devices with microcontrollers

View on HN

That's what I initially thought too, though having read and understood little of the article, is sqlite not a consideration too? Or does it take up too much memory?

There's a pretty good write up on running sqlite on an STM32 here: https://github.com/luismeruje/SQLite-STM32

Keeping in mind that STM32 is on the high end of what you might call embedded, and the writeup is pretty clear that it barely fits/works there, lots of caveats, etc.

Another thing to consider is that sqlite dynamically allocates memory. You typically want to avoid that in embedded. Everything is slow, memory is scarce. The sheer code size is also a issue.

Sqlite has a mode where you can give it an area of memory and it will never use any other memory.

It's still going to dynamically allocate its memory in there, isn't it? This is a slow operation.

Memory allocation isn’t that slow (in fact all the ram is SRAM which is typically quite fast), it’s just that you only have 256k-1M RAM in total. This means that any time you’re saving later by trying to fill space now ends up getting wasted when that memory needs to be reclaimed.

SQLite would require a file system. Embedded systems typically do not have this.

SQLite doesn’t require a file system per se, as you can create an in-memory db and then use vfs to load/write the actual data from/to your IO layer.

Though note you can define your own "Virtual File System" (VFS) for SQLite to use[1]. It might be a bit of an undertaking, but I think you could use that to run on just about anything with storage you control. (I haven't done it myself, just some research back in the day)

[1] https://www.sqlite.org/c3ref/vfs_find.html

Reply on news.ycombinator.com