Glassdb: transactional object storage
I was frustrated by the gap between stateless and stateful applications in the cloud. While I could easily spin up a stateless application as a “serverless” function in any major cloud provider and pretty much forget about it, persisting data between requests was a game of pick two among three: cheap, strongly consistent, portable.
Could I solve portability and lack of transactions myself with a single client-side solution? I thought it would be possible through object storage (e.g. AWS S3), which is strongly consistent, ubiquitous and cheap.
Yes, I could rely on a “serverless database” and just build a thin conversion layer between DynamoDB (AWS), Cosmos DB (Azure) and Firestore (GCP). So, does it make sense to instead reinvent a database almost from scratch? Not in a practical sense, but think about it this way: I learned a lot about database design, so it was still worth it, and I think you will find my journey useful too.
My thinking started a few years back, when I realized I could easily deploy serverless solutions – like AWS Lambda or Google Cloud Run – to deploy a function that handles HTTP requests, without worrying about host OS updates, Kubernetes clusters, VMs, and all the underlying infrastructure. And since the serverless billing is a pay-per-request (with a decent free tier), I also paid little to nothing for most of the services I was running for myself.
