I use postgres on my raspberry Pi 3B as my development server (along with PostgREST and Nginx) and it has served me faithfully for more than a year. Many people are surprised to see the setup and how fast it is to spin up a backend server. The response time is also pretty good and it's amazing to see such a tiny machine pull off such a feat.
I love postrgres, and obviously this is just a test, but for anything where I would use a pi sqlite is insanely good.<p>I use sqlite for full fledged websites with millions of rows with no issue, fast, easy to deploy, easy to move.
Redis is quite fast on the Pi3, completely another story compared to the original Pi. With AOF enabled and fsync policy every second, without using pipelining it does 28k ops/sec. With pipelining it reaches 80k easily. Not bad for a hardware that is quite cheap and limited. About the problems with the SD card, in the specific case of Redis there are mitigations <i>if</i> it is possible to give up on durability. One could use snapshotting and configure a delay that will not trash the SD too much. I think PostgreSQL does a lot of random access in the on-disk btree, but other systems using some log structured storage in append only should create less problems in theory.
Please for the love of god, do not use Postgres on a SD card, you'll corrupt it quickly, even spinning rust over USB2.0 is faster and more reliable. That's my experience with it at least.
You better have some good redundancy on those SD cards because I've run Pi clusters before and most of those cards go corrupt pretty quickly with any frequent number of writes.
I'm wary of running anything with data I care about on a device without ECC RAM.<p>From the docs:<p>> PostgreSQL does not protect against correctable memory errors and it is assumed you will operate using RAM that uses industry standard Error Correcting Codes (ECC) or better protection.<p><a href="https://www.postgresql.org/docs/11/wal-reliability.html" rel="nofollow">https://www.postgresql.org/docs/11/wal-reliability.html</a><p>Re: IS ECC RAM really needed?<p><a href="https://www.postgresql.org/message-id/20070526145214.GA21290@mark.mielke.cc" rel="nofollow">https://www.postgresql.org/message-id/20070526145214.GA21290...</a>
If the storage is handled properly, RPi can do wonders.<p>I've used RPi1 as a git sever in our company for 5 years with encrypted USB flash drive as storage.<p>We must have committed at-least a million lines of code into it & we were using it every day.<p>Except for changing some memory related flags in git, I didn't change much w.r.t to git.<p>I had another encrypted USB flash drive to which the files were backed up, interestingly this flash drive failed but the primary drive never died till date.<p>The git server is running 24*7 on RPi1 for past 5 years.
cool article!<p>It would be great to know the SDCard speed and maybe see some comparisons based on the SDCard type since the speeds vary quite a bit<p>see also: <a href="https://en.wikipedia.org/wiki/SD_card#Speed" rel="nofollow">https://en.wikipedia.org/wiki/SD_card#Speed</a>
They need to re-test on the grid using different PI for each version. And then re-test using same pi, different SD card.<p>Beecause it is clear from the bad SD card comment that the SD card and PI can influence the speed of the tests.
I only read the title; but I'm expecting performance generally to be abysmal.<p>I/O is quite poor on rPIs and that's what PostgreSQL needs more than anything. More than memory or CPU for sure.<p>The best thing you can ever do for your database is (in this order):<p>1) Have enough ram to fit your entire dataset (mostly due to joins)<p>2) Have the best raid card money can buy.<p>--<p>An SD card is shocking enough but on the rPI it's going over a USB bridge which takes CPU cycles too!<p>Still probably performs better than postgresql on WSL; since the I/O is the major bottleneck there too.