6 ms·
> Why not just use the right tool for the job ? (i.e. hosted DB or compute). Because sometimes you want a database for 10000 rows, or you have 5 logins a month
by rad_gruchalski 4y ago
> Why not just use the right tool for the job ? (i.e. hosted DB or compute).
Because sometimes you want a database for 10000 rows, or you have 5 logins a month and you don't want a $30/month database running in the cloud.
There's a market out there for real "server-less" database that charges you per rows stored, is priced per read/write operations, and is reasonably priced for a 10000 rows per month, without having to calculate how many 4KB blocks you are going to read or write.
- quickthrower2 4y agoFirebase Firestore?
- endisneigh 4y agoLike… dynamodb?
- Brystephor 4y agoDynamodb doesn't do well with complex queries. Imagine you've got 4 integer fields, any combination of which can be filtered by a range. Using dynamoDb, you're going to have a hard time querying if field A, B, and D are included. If you add a fifth field, it's going to be a pain to add to historical data.
- endisneigh 4y agoYes but if you only have 10k rows it’s trivial to do manual joins or migrations
- deleted 4y ago[deleted]
- rad_gruchalski 4y agoMaybe my 10000 rows are 5 tables, 2000 rows each, and I want to have some regular SQL features like joins? Can I do that without having to do joins in code? Because if I have to do joins in code, I can just store data in flat files and process everything in memory. But what if I want to have an existing app designed to run against a db system? If I have to start writing joins by hand, what's the point of even having a database?