3 ms·
> My opinion, when going serverless, I wouldn’t think of using RDBMS’s (although you can) and instead use databases like Elasticsearch, DynamoDB, Mongo etc. Th
by ahallock 10y ago
> My opinion, when going serverless, I wouldn’t think of using RDBMS’s (although you can) and instead use databases like Elasticsearch, DynamoDB, Mongo etc.
This is a vague statement that's not really based on evidence, and I'm not sure why using Postgres, for example, is going to be so much worse for most use cases than these NoSQL solutions.
- joecot 10y agoAs I explain over here (https://news.ycombinator.com/item?id=13774041 https://news.ycombinator.com/item?id=13774041), trying to use Lambdas with your existing servers, like Postgres, can cause some serious complications.
- bpicolo 10y agoIf that's the case, seems like a great argument against using lambda ;) Side note, is that just startup time for a single lambda `node`? Won't you be running >>1 node and not really care about startup time for any single node?
- joecot 10y agoIt's every time you have to start up a lambda instance. So if you're low, continuous traffic, it'll happen once and you won't really care. If you're high traffic, occasionally different instances will get started up, will also need their node network interface, and also take 6+ seconds. And if you're low traffic but not continuous, if there's a pause for more than around 15 minutes (entirely depends on how much demand there is for lambda and how rapidly they clean up old containers), for the next request you get you'll have to cold start again.
- ahallock 10y agoThanks for the explanation. So it isn't really RDBMS vs NoSQL inside Lambda, but issues with using Lambda on your own VPC.