"Holy Grail" Serverless #56
Replies: 3 comments 7 replies
-
The problem with SQL & serverless is that SQLite requires a single writer while serverless has no concept of that. It could work if you essentially treated writes as a network connection (like ODBC) to a central service but all reads could happen locally on the serverless function. You'd also have to replicate your database down to all instances of the serverless functions so they could get fast reads but that could be problematic with a large database. IIRC, functions go cold after just a few minutes so you'd need to keep them warm to have any possibility of persisting the local DB copy. |
Beta Was this translation helpful? Give feedback.
-
The biggest drawback of serverless architecture is the weight of context and costs of saving/restoring it |
Beta Was this translation helpful? Give feedback.
-
This is another to skin the serverless db cat https://github.com/psanford/donutdb It’s using was but it shows the concept of mapping the SQLite volume from a shared persistent resource S3 Can and should still be used for the WAL and clustering for Read only Gooogle cloud run using their new Filestore requires a proxy in the middle and I suspect it will get expensive but I have not looked deeply into it |
Beta Was this translation helpful? Give feedback.
-
On Reddit you shared,
I agree that would be awesome! I envision you start from a serverless runtime (Lambda/OF/Kn/KEDA) and provide the app developer a SQL interface. The added benefit of this model is local development/testing becomes trivial even with litestream not available (I think?)
What are some of the challenges you foresee? I imagine #1 & #8 are part of the answer but are there others?
Beta Was this translation helpful? Give feedback.
All reactions