After extensive testing on a number of test Nerves devices, I was finally able to identify the issue that @Qqwy reported.
It was a bug with the way the most recent database file is chosen, in cases when a restart happens right after a compaction, but before the old file is cleaned up, and CubDB sees more than one database file. The wrong file was chosen, leading to the new records disappearing.
The issue is solved with the latest release, v0.12.0, which is 100% backward compatible. Thanks a lot @Qqwy for reporting and helping. Version 1.0 is getting closer, thanks to valuable feedback from people in this forum 
I get error :erofs when I try to start CubDB. Still pretty new to nerves, what am I doing wrong?
Hi @ryanwinchester , thanks for giving CubDB a try
erofs is normally indicating that you are trying to write on a read-only file system (see the documentation of file-related error codes here). Double-check if the location of your data directory is read-only.
If you are on Nerves, one thing to know is that most partitions are read-only (in order to protect the firmware from corruption). You can use a directory under /root as your data directory for CubDB (e.g. /root/db, which will be created by CubDB if not existing), as the partition mounted at /root is read/write.
I hope this helps
P.S. I’ve been using CubDB for some smaller configuration databases. Been running fine for a month or so with no corruption or other issues. Nice work!
Thanks for the great feedback @elcritch ! It’s great to hear you are finding CubDB useful and reliable 
As for me, I am running CubDB in a customer-facing product for data logging and to persist configuration. As the project creator, I was a very early adopter, so I initially had to deal with occasional issues, but all is running very smoothly since months now, on multiple devices deployed remotely.
In other words, CubDB is a version 0.x.y because a database deserves extensive testing in a variety of scenarios before being declared v1, but it’s used in production with stability requirements. It’s API won’t unexpectedly change in backwards incompatible ways, unless strictly needed and clearly communicated.
Always very valuable for me to hear users’ feedback
It’s working good for me now as well, thanks for the help.
Mainly config persistence here as well, but won’t be in production for a few months yet.
Hello,
I have this error this morning:
[error] 'File operation error: emfile. Target: /usr/local/Cellar/erlang/22.1.8/lib/erlang/lib/stdlib-3.10/ebin/sys.beam. Function: get_file. Process: code_server.'
[error] 'File operation error: emfile. Target: sys.beam. Function: get_file. Process: code_server.'
[error] 'File operation error: emfile. Target: /usr/local/Cellar/elixir/1.9.4/bin/../lib/logger/ebin/Elixir.Logger.Translator.beam. Function: get_file. Process: code_server.'
[error] Task #PID<0.228.0> started from #PID<0.225.0> terminating
** (stop) exited in: GenServer.call(Gem.EventsTest.Repo, {:get_and_update_multi, [{Gem.EventsTest.Account, 1575890069540}], #Function<9.14759660/1 in CubDB.get_multi/3>}, 5000)
** (EXIT) an exception was raised:
** (UndefinedFunctionError) function :sys.get_log/1 is undefined (module :sys is not available)
(stdlib) :sys.get_log([])
(stdlib) gen_server.erl:888: :gen_server.error_info/7
(stdlib) gen_server.erl:869: :gen_server.terminate/10
(stdlib) proc_lib.erl:249: :proc_lib.init_p_do_apply/3
(elixir) lib/gen_server.ex:1009: GenServer.call/3
(cubdb) lib/cubdb.ex:506: CubDB.get_multi/3
The context is I am doing a lot of writes and reads per second. I post here (not on the repo) because it seems that it is not related to CubDB but to the erlang runtime : for some reason the :sys module seems undefined after some point. But maybe you have encountered this before ?
This happens after a good amount of read/writes, not from the get go.
Hi @lud,
Thanks for reporting this. As you already mention, I think this is not directly related to CubDB. It seems that the error about :sys might be a side effect of the emfile error. The emfile error indicated that too many files are open.
CubDB only keeps a single file open (or two during a compaction), and performs all low-level file operations through the same process, so a high volume of read/writes should not cause too many files to be opened.
A few ideas:
Could this be caused by some logger? I see a reference to Elixir.Logger, maybe that’s something worth investigating.
Do you, by any chance, start multiple CubDB processes? I should clarify this better in the docs: only one CubDB process for the same data directory should be created. Other processes can concurrently call it, so if you need to perform many parallel operations from many processes, you still start a single CubDB, and then call it from multiple “parallel” processes. Not sure if this is your case, but just making sure as you mention many read/writes.
I never encountered this error, but I’d be interested in knowing what you find out. Should this turn out to be related to CubDB, I will work on a fix.
To give some more context on top of what @lucaong already said: How I have it configured is by starting CubDB using a database location fetched from the application environment (i.e. Application.get_env(:my_app, :myimportant_db_location) which I have configured to point to data/myimportant_db in the config/config.exs but to point to /root/data/myimportant_db in config/target.exs. This means that CubDB will work normally (and self-contained to the application we’re working on) when running it on the host machine, but will properly work by using a subdirectory of /root when running it on the Nerves device as well.