github.com/simpleiot/simpleiot@v0.18.3/docs/ref/store.md (about) 1 # Simple IoT Store 2 3 We currently use SQLite to implement the persistent store for Simple IoT. Each 4 instance (cloud, edge, etc.) has its own store that must be synchronized with 5 replicas of the data located in other instances. 6 7 ## Reasons for using SQLite 8 9 We have evaluated BoltDB, Genji, and various other Go key/value stores in the 10 past and settled on SQLite for the following reasons: 11 12 - **Reliability**: SQLite is very well tested and 13 [handles things](https://www.sqlite.org/transactional.html) like program/OS 14 crashes, power failures, etc. It is important that the configuration for a 15 system never become corrupt to the point where it won't load. 16 - **Stable file format**: Dealing with file format changes is not something we 17 want to deal with when we have 100's of systems in the field. A SQLite file is 18 very portable across time and between systems. 19 - **Pure Go**: There is now a 20 [pure Go version](https://pkg.go.dev/modernc.org/sqlite) of SQLite. If more 21 performance is needed or smaller binary size, the native version of SQLite can 22 still be used. 23 - **The relational model**: it seems to make sense to store points and nodes in 24 separate tables. This allows us to update points more quickly as it is a 25 separate line in the DB. It also seems like flat data structures are generally 26 a good thing versus deeply nested objects. 27 - **Fast**: SQLite does read caching, and other things that make it quite fast. 28 - **Lots of innovation around SQLite**: 29 [LiteFS](https://github.com/superfly/litefs), 30 [Litestream](https://litestream.io/), etc. 31 - **Multi-process**: SQLite 32 [supports multiple processes](https://www.sqlite.org/faq.html#q5). While we 33 don't really need this for core functionality, it is very handy for debugging, 34 and there may be instances where you need multiple applications in your stack.