Yeah. I think the whole point of Spanner is to handle larger, larger, larger workloads and databases, and if you can fit everything on a single server, you definitely should.
Comparing Postgres to Spanner is kind of like comparing a delivery van to a train. The train is always going to have higher overhead costs.
Linux admin is a useful skill, but I know my Linux admin skills can’t compete with the reliability, availability, and scalability of cloud systems… like Dynamo, S3, Spanner, etc.
> decided I might as well give up and learn the basics of Linux admin once and apply it for life.
Yeah I think this raises an underappreciated drawback of working on heavily AWS/GCP native projects. So much of the time ends up being spent on service level config and troubleshooting that has little relevance elsewhere.
Or you could use DynamoDB for basically free. One month of 1GB of storage, 1kb item size, 100,000 writes, and 100,000 reads, would be $0.39 on DynamoDB on-demand. A million writes and reads respectively would be $1.63. Strongly consistent reads'd make that $1.75, and transactional writes would make it $3.00
I get it but I feel like it isn't really mine, and learning this new db/console/product/vendor that won't be around in 10-20-30 years is a waste of very limited time.
Linux admin + hosting a server = my data, on my terms, until I keel over, and possibly long after that.
By the time DynamoDB goes away, that Linux server you have will have been EOL for two decades and chock full of security holes, not to mention disks filling up or getting wiped. The amount of time you'll spend tinkering with your server will dwarf the tiny amount of time it'd take to replace DynamoDB with an alternative service.
- in the next few decades, my Linux servers will have been updated completely multiple times
- software updates happen on my schedule and at my behest
- I can move to newer hardware whenever the mood strikes me
- I maintain full de jure and de facto ownership of my data (AKA I control it completely)
- Since I own the data, I can always upload it to some vendor in future. Due to vendor lock-in, non-standard data formats, and my least favourite: data egress fees, it's not straightforward to go from a vendor to another vendor, or from a vendor to DIY. I maintain maximum optionality
- Since I committed to the private server path, I can take full advantage of the server being a general computing device. I can combine web-hosting, databases, and other things on the same device / a stable of devices. I end up having ridiculous performance, full control of my entire stack, and at a huge discount, and it's a very simple system.
Security concerns are addressed in a couple of ways:
- By having everything on one server, or by architecting things just so, I can stand up a database that does everything I need, including serving my web-apps, without ever facing the public internet directly.
- Maintaining a secure server is admittedly more of an ongoing chore, but it's not a significant timesink at all
- Every online service by AWS et al ultimately runs on a server much like mine, so if there's some serious widespread Linux vulnerability, it'll affect managed services just as much as my server.
- The managed services themselves are not only juicy targets but are themselves vulnerable to both hacking and phishing. I'm convinced SSH'ing into Postgres + Linux is a safer option than a more complicated structure.
All of the above assumes my apps will never be planet-scale, which even in the most bullish case, they never need to be.
And for 65/month, you can get a VERY beefy Hetzner server.
You’ll have to wade through the crazy thicket that is the menu of cloud offerings.
I gave that one look, and decided I might as well give up and learn the basics of Linux admin once and apply it for life.