Hacker News Reader

We do this all the time. Our tests run against SQLite (I use Mariadb in prod).

Each parallel testrun gets its own path in /dev/shm/xx so everything is in ram as well.

If you're using SQLite, why the indirection of an in-memory filesystem rather than SQLite's in-memory database feature?

Not the person you're asking this, but N connections to sqlite :memory: backend results in N separate database instances.

This can be worked around in some scenarios, but not always & reliably. Most importantly, you can't reach the same in-memory database from multiple processes.

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

I have used libeatmydata to help with this, but you just made me realize that in my current project I could just dump the test db to RAM. Thanks for the tip!

For integration testing I'm sure people do all sorts of "interesting" things. For unit tests in an automated CI build, it is often more desirable to have a smaller subset of data, which presumably is less slow, since tests there also focus on more isolated workflows.