I don't know how well the other solutions would scale to your 1TB database requirement so I can't speak to that. I have to admit that I find it a little difficult to believe that a 1TB base database has no ACID requirements but whatever.
I have a similar database but it's for phone call recordings. The main database is only several 10's of GB of data and the remainder of the 1TB database is call recordings. I elected to store them in a large but partitioned table because no one protects data like a DBA. When I first took a look at what they were doing, they had the data stored in files. Over time, 10% had gone missing and another 10% had gone corrupt. Both of those observations are what made me decide to store the data in the database itself.
That, notwithstanding, if you do decide to stick with SQL Server, check out FILESTREAM at the following URL:
If that doesn't quite float the boat for you, you can easily develop a bit more of a customized solution where the data is stored in zip files on a disk, use SQL Server to keep track of the file paths and name in a table, and use xp_CmdShell or an EXEC Task to locate the file, unzip it, and either return the contents of the unzipped file or leave it for some app to pick up on. Doing such a thing might bring your 25TB requirement down to only 5TB thanks to the typical 80% compression that a zipped file frequently enjoys.
The good part about all of that is 1) you wouldn't have to learn a new DB or "NoSQL" solution, 2) the 5TB requirement might be small enough to just buy some extra-disk for the on-premise hardware, which would eliminate the expense of cloud storage and data retrieval from the cloud altogether (although you'd have to provide your own DR solution but I assume you have one already), and 3) if the requirements ever do change in the next 10 years to have a need for ACID, then you won't have to change back to an RDBMS because you'll already be there.