Since you don’t and apparently not going to have an UPS you need an SSD with PLP.
Also, Evo is poor choice for databases even if it had PLP — it’s MLC flash (albeit with small SLC cache in front). It is not designed for database workloads; it’s optimized for being a system drive in a pc.
since im not going to put anything of relevance on the disk, exept storj databases and maybe storj program, and maybe the identity (identity will have (multiple) cloud backups), what would happen if i lose all of the data on the spare nvme? nothing to bad, i think. 
550,000 IOPS random write and 600TBW 5Y warranty will be good enough. nothing is 100% secure.
but what are the risks? what are the risks of an failing cheap battery?
its already like the 5th wheel on a car. its not an high reliable server…
it’s better to store it on the disk with data, because they are tied together, data without an identity is useless, and the identity without data is useless too.
However, sometimes the identity can be corrupted, for this case the backup copy of the identity would be helpful.
I agree, data on the node can suffer few lost bytes here and there. But this not the only thing that will happen.
You will lose your time. Every abrupt reset will corrupt your database and node will fail to start. You will have to delete databases to fix that. What if you are away? Your node will be stopped until you return. Downtime accumulates, and then you have to think — interrupt my trip or save the node.
In this case why bother with SSD — put databases on ramdisk.
You will lose money: this workload will chew thorough this endurance in a matter of months due to write amplification. These numbers are for ideal scenarios. Your databases write random io in sync mode — every few bytes written and synced will result in 4K sector writes. You will murder your SSD very fast (few months to an year) and will need to buy a new one.
You can disable sync — but then see above — might as well save money and use ramdisk.
And we are not talking about actual power conditioning here, just SSD wear and data consistency that directly translate to your costs.
So risks are clear — it’s at least your time and money. Do you value those more than $50 for a cheap UPS?
You are misunderstanding the purpose of a UPS. It is needed to be able to sustain power long enough to shut down your server gracefully: exit processes and sync filesystems. Lead acid batteries is a very old technology. There is no difference between cheap and expensive batteries for this purpose, and you will be replacing them anyway every two years.
As a result your dbs won’t be getting corrupted, you won’t risk losing data, (you would not have to replicate identify everywhere- why is it on SSD in the first place? Put it to HDD) — you save time, money, and shield your equipment (at least the expensive high quality power supply) from brownouts and surges.
to summarize:
“Teamviever” or “VNC” will do it.
it will be restarted from windows after some minutes. + i get notified via uptimerobot anyway.
I will crank up the wear leveling space via samsung magician and monitoring it closely.
It has still warranty then?
No, i will not need to buy anew one, since there are 2 alternatives (storj hdd)
adding extra cost to the u said “cheap” UPS.
No, i meant failing like leak,or explode,or simply not working long enough.
Ok, il do it my way. I considered everything you wrote.
See it as an experiment or learning by doing
I wouldn’t worry about that with just storage nodes and any even half-decent consumer drive. Got a Lexar NQ100 240 GB 3 months ago for around 20 USD. Used as a system drive on my NAS plus holds databases for 5 HDDs worth of nodes. Documentation states 84 TBW and a 3-year warranty. Mine’s got 3.74 TB written so far, meaning I’ll run out of vendor-guaranteed writes in >5 years.
While databases as a category of software indeed do a lot of synchronized random writes compared to other types of storage software, storage nodes don’t put the same load on a database as, let say, a busy web application. Besides, storage nodes are configured to use their SQLite databases in WAL mode, lessening the impact:
I disagree. It is better to configure a remote access to the node to be able to fix something or start it remotely, than lose all stat every time. You may re-create only corrupted database or fix it if the stat is important for you @daki82
For example, I used a remote controlled AC plug for my rpi node, because well - it may hang when I far away (now more than a year). So it’s helpful. However, the SD card is broken again recently, so smart plug doesn’t help anymore 
Thanks for this info. It realy chills my mind.
Hardware arrived today.
The database on a node is very small, under 100meg so that using say a 256gb SSD is not going to do anything much with writes spread over that space. If in doubt run one for a while and use SMART tools to check its lifespan. You could also google SSD life span as now days they are quite robust compared to years back. Also small SSD’s are so cheap now.
sounds like sd card not so reliable solution 
yes, but it worked 4 years. I may replace or simple reflash it, as I usually did (2 times), just I have no route to there.
The issue with SD cards (as well as USB thumb drives) is usually abysmal to horrible wear leveling: if you repeatedly rewrite the same block of data big SSDs will keep read-modify-write data to new and different physical segments. SD cards will likely end up actually rewriting the same physical block. This is the case with databases, FAT filesystems, and stuff like SMB caches. This is why reflashing helps here — it forces already worn out blocks to be remapped.
There are a few solutions out there to mitigate this. The frequently employed one is to have boot volume on an SD card but avoid writing to it - move all logs, databases, and caches elsewhere via overlay filesystem: to external storage device or even RAM disk. Notable example is FreeNAS/TrueNAS: the boot snapshot is readonly and all configuration is done in runtime, all mutable data lives on the system dataset, that can be relocated to magnetic media.
So, if you take these precautions — you can definitely use SD card as a boot drive : the only writes would be system updates, and endurance will last for decades. I myself boot my TrueNAS system from some cheap horrid USB thumb drive from Ali express. There are no writes to it and it has been working for years.
In my case it corrupts system files after 2 years or so during updates (just reapplying all packages do help, I just forgot to do that and when I remembered, was too late - it did not boot anymore). I did not care too much, because it’s easy and quick to reflash it. I disabled other writes, except system logs, but node’s logs are going to the HDD with data.
If I would have a route to there, I likely could do it again, but this node is lost due to a long downtime.
Question: Are there any performance benefits of deleting the databases each month, if they are on the same HDD as the storage?
If you accept the history loss, will keeping databases small, by deleting and recreating them each month, have any performance improvements?
Maybe a bit, yeah, it should be a bit faster. How much, hard to say—for a month worth of data I’d risk a guess that the difference would be below measurement error. Maybe you would only see some difference in the first few days after deleting?
only if they are buggy and bloated, otherwise moving them to eg: an usbstick or better an ssd
would make much more sense to reduce load on data disk.
After weeks of preparations (portforwarding, firewall, av, hardware choosing, identity, dust removal, upgrade to windows 11, planning, software installing, uptimerobot, formating, yaml-config editing, services tuning etc…)
So today was the day:
Node has the Toshiba 20TB wich is a Beast. it goes brrr…but i hear no brrr… its not nearly as loud as i tought. maybe its later louder.
(now the SAMSUNG 970 EVO Plus 1 TB M2 is pure overkill atm., maybe it will hold the databases later. For now it holds the swapfile and the storj installation+log. overprovisioning 10% on)
the gpt table minimum cluster size for the disk is 8kb already.
It was a smooth start without errors. Second Node online, 500MB ingress already. Yayyyy!
Thanks to the whole community !
There is no point in wasting SSD space for swap file. If you are running out of ram you have bigger issues to deal with, and performance was already gone the second disk cache got evicted.
There is no reason to over provision EVO. There is SLC ssd buffer in front of MLC bulk nand.
So i put it to HDD? just joking…why not on te 2nd faster ssd?
so, there is a reason to not doing it ???
or do you want me to buy primocache?
Yes. Becase swap shall not be used at all under normal operation. Therefore it does not matter where it is. It’s not performance critical. And space on hdd is cheaper.
I don’t see how promo cause is relevant here. I was taking about SSD buffer cache inside Evo, in front of slower nand, that is already overprovisioned. No need to overprovisioj on top again.