> We're going to keep testing Hetzner Cloud with new applications and use cases going into the future. While they are a very new player in the crowded Cloud Provider market, and their offerings are much more limited, the pricing is a breath of fresh air from the large three providers.
I've found Equinix [1] cheap, and really good. It's 100% bare metal. I've never had a problem with it. And the DC servers (at least) are often equipped with Mellanox Connect5 NICs great if you're into low level systems programming. There's on-demand, reserved, and spot server options. I typically spend $0.75/hr for the smallest instance to about $1/hr for a medium instance. They have private LANs, some flexibility with floating IP addresses. It supports IPV6. Disk and RAM is more than what I've ever needed. You get a root login over ssh.
Possible negatives depending on your needs:
- no AMAZON AMI: I don't think you can boot your custom O/S. While they have a large choice of OS, it's nowhere close to what AWS provides
- Wider cloud offerings S3, lamba, DBs etc. are not available. You have to setup all that stuff yourself.
This has been posted and reposted continuously for a year and I still don’t understand the comparisons in the article. Either use SQLite across the board or use MySQL/Postgres across the board. Or do both. You can even model a self-managed rdbms install on the clouds that don’t have that turnkey offering. But mixing and matching makes no sense.
I’m a huge fan of SQLite and have open sourced some .NET stuff around it (eg https://github.com/neosmart/AspSqliteCache ) but learned a very expensive mistake in using it for an ASP.NET Core Project with the default pattern (i.e. with EF Core).
SQLite locks (tables or the entire db depending on configuration) upon write. If you use shared cache mode and WAL you can get very far with one write thread and many competing reads - depending on shared cache mode, WAL, and other options. I benchmarked the different configurations with one or more writing threads here to show how it scales: https://github.com/mqudsi/sqlite-readers-writers
But this approach is hard to model with EF Core. If you use the default request-scoped DI injected connection, you risk any writes upgrading the read lock to a write lock for the duration of the request. The better approach is to use the default request-scoped connection for RO operations and then request a scoped/transient DI connection for any write ops, but copying internal EF entity tracking state from one EF instance to another is tedious and fraught with issues. You’re at least able to work around this if you try to always keep in mind write transaction lifetimes, though.
The problem comes as soon as you need a “background service” in the sense of “an operation running independently of requests and parallel to them.” If that service needs a write lock for any amount of time, you’re suddenly going to be seeing write timeouts (since default behavior is to poll repeatedly until a write lock is obtained) and that is pretty much impossible to fix.
As one of the biggest advantages of using a resident executor like .NET or Java vs a per-request stateless option like PHP is that you can do stuff independent of requests, SQLite is tricky to use correctly in prod in this model.
The good news is that if you use the SQLite EF provider and run into this, it’s usually not too hard to switch to a real DB provider as a lot of the work is abstracted. (Especially Postgres because even manually crafted SQLite queries will likely run as-is or with little alteration, given that they are - largely - modeled after the Postgres ones.)
If you do want to build a (web or otherwise) service around an SQLite database, the best model I’ve found is to use a language with first-class channel (with queuing) support (rust, go, and of late, C# too) and have a dedicated write thread. Servicing threads should have direct RO db access but model any writes or updates as requests posted to the channel (or priority channel). Bonus points if your type system prevents you from accidentally or purposely upgrading an RO service thread/fiber’s db connection to an RW one.
Wow, just want to say that this parent comment is so great. Good criticisms along with demonstrated in-depth knowledge and shared for others' benefit.
Did the parent comment author play with the mmap / synchronous / temp_store options in their tests? Wondering how those affect the write performance. I know those options from this article: https://blog.wesleyac.com/posts/consider-sqlite
I'm running my SaaS web app with a SQLite db, Node/JS, and Litestream. Getting some number of millions of requests per month and haven't needed to dive in to tuning yet, but I'm curious about it and there's not a lot of data or guides about folks using SQLite as their production db, especially with specific languages or frameworks.
Those options you named will mainly change the specific performance characteristics but not have any impact on architectural matters. I.E. they’ll give you a bit more or less oomph out of a node but typically not make or break your app design.
If you look at the GitHub benchmark I linked, you’ll see how the specific parameters I was referring to give order of magnitude changes in performance whereas eg something like using mmap over distinct syscalls will likely only give you single- or low double-digit gains depending on your configuration (more with speculative execution workarounds enabled on older hardware, less without or on newer).
(Synchronous isn’t an pragma option that you can just enable or disable since it has actual ACID ramifications - i.e. either your usage will let you do it or it won’t.)
Sure, if you are even able to sign up to it... every single time I've tried signing up it has been blocked, I've tried several emails and cards without success, a lot of other people are also experiencing the same issue.
I was going to comment about that as I’ve recently found their mid-tier+ offerings to be the most price competitive. Their barebones offering are not the cheapest but everything else is a better deal than Hetzner and DigitalOcean, let alone the bigger names.
