21 comments

[ 2.2 ms ] story [ 41.4 ms ] thread
Very nice. Esp32 soon?
It's already there under demos/esp32_spi_flash.
I know very little about the embedded world. Does anyone familiar with that space know how this compares to SQLite?
SQLite is too high level. Maybe compare it with LMDB.
I would like also to see comparison with lmdb, didn't dig into code, but from doc I didn't see it supporting multithreading
I came to ask this. I went straight onto the website to look for SQLite comparison. It's after all the dominating embedded database.

I do realize the use cases can be different, but then say and show that in the comparison.

(I'm trying to be helpful by offering unsolicited advice :) - Brilliant work!

I haven't checked, but they probably try to retain buffers as long as possible in order to reduce reads and writes.
Maybe not. This is listed as a key feature:

> Very small footprint, ram usage is almost 0;

It wasn't clear from the title that this is a db designed for embedded devices (unlike for example SQLite that belongs to the family of in-app embedded databases). One of the interesting features in this db is wear leveling a technique used for prolonging the service life of flash storage media.
"Different from traditional database based on file system, FlashDB combines the features of Flash and has strong performance and reliability"

What does this mean?

Do they mean "Flash" as in 'flash memory' i.e. SSDs?

The way it's written it seems like "Flash" is some other product, but it's not detailed anywhere.

Flash storage is what routers have used for ages, while an SSD can contain Flash storage, it does not mean that Flash storage is an SSD.

https://www.cdw.com/content/cdw/en/articles/datacenter/diffe...

I'm not fully hardware savvy so feel free to correct me.

This article seems to be confused or maybe just grinding for SEO. Eg the section "Difference Between Flash and SSD Storage" doesn't cover the question, just has random flash facts and then makes some confused distinction based on form factor.

SSD is a higher abstraction term covering storage technologies like DRAM, SDRAM, and XPoint in addition to flash, and implies there's a storage management layer that presents a block addressable interface (like SATA or NVMe or USB storage etc). This layer also known as a FTL. The non-flash part is not practically very relevant those are extremely niche or extinct. But the abstraction part is relevant, some flash storage presents as SSD and some doesn't. For the latter the device storage driver stack needs to have more intimate flash device knowledge, and using specific flash device filesystem.

In the context of FlashDB, it supports raw flash without the SSD abstraction. This is to be expected as tiny embedded devices typically have raw flash and not SSDs. Eg here: https://armink.github.io/FlashDB/#/demo-esp8266-spi-flash

> maybe just grinding for SEO

Was the first link on Google, so very possible.

Flash as in Shazam, aka the literal application of lightening. /s
Flash as in raw flash (e.g. connected via SPI). An SSD has many abstraction layers (and usually a file system) between the application and the flash.
Thanks, I eventually guessed it must mean "flash storage" or "flash memory".

The word "flash" by itself didn't mean anything to me, and especially capitalised as "Flash" made it look like a product name.

Flash as in Macromedia/Adobe Flash
From a brief skim of the website, it can be used on very small controllers such as STM32 and ESP8266 (which gives a whole new meaning to the word embedded). It's smaller than SQLite, so mainly for microcontrollers, that is, direct access to the flash memory without a filesystem in between, but also can be used on Linux through the filesystem.