31–40 of 72 posts
The example shown has 14GB of data, which is absolutely tiny, yet it can still rack up $40k in costs per day if used incorrectly (i.e. less than optimal, but not egregiously wrong)? Why would you use this?
Can’t think of a worse advertisement for their product.
Earlier quoted context omitted.
Quoted post unavailable.
Never ever become 'the SQL guy' in your group. No one wants to learn it. SQL is the intersection of set theory, computational theory, network usage, cpu usage, and laziness. "your table is 120 columns wide and nothing but strings with no rules of the data types and no indexes, sooooo your perf is a bit slow huh?" "yeah how did you know?" "wild guess"
What? Even if I used SQLite on my laptop and queried this thing every second, I'd still use <$3 a day. Also, this platform has no concept of caching? Don't understand this post at all, total clickbait based on an inefficiency in your platform you really shouldn't be advertising.
If you want to stop out of control spend, have your analysts learn SQL. Avoid database systems that charge per query (like tinybird) and make damn certain your people know SQL if you do. Ignore and preferably fire people who mention things like “data lakes”.
oh my god
i'm currently $13k/mo in dynamodb costs because of this whereas the same requirements sql database costs $2k/mo
Earlier quoted context omitted.
Seriously? A $10k dedicated server would have a payback period measured in minutes.
It depends on the business unit. Some don't have the ability to run a technology group to run a $10K dedicated server.
Earlier quoted context omitted.
1000% this Almost every solution I've seen to tooling that is supposed to "avoid data analysts having to learn SQL" is far more costly, requires engineering staffing, performs much slower and sometimes requires the analyst to instead learn some esoteric less powerful language ... If your job is to slice&dice data all day, and can't be bothered to learn SQL, I don't know what to say.
The data lake problem is specifically due to microservices or SOA. People love to separate customers from orders until they realize that you want to do complex filtering on customers and join it to their orders. Then everyone says "oh crap" when they realize they've created a problem without a great solution.
Personally I view a true document (not a table row turned into JSON) as being the deeply-nested kind, and ideally generated from the relational data itself, to allow different "dimensionalities" to be represented without needing pivots/windows/analytical queries, and that's very seldom what I see it being used for in practice. Again, most people just have a RDBMS row but stored in JSON.
example: in the "netflix" example, your movies, your actors, your users, your likes, etc are all relational, and then you build a document collection that is good for searching movies, a collection that is good for displaying user data/history/settings, a collection for displaying actors' filmography, etc, but all are generated from the same actual, consistent relational data.
Earlier quoted context omitted.
Seriously? A $10k dedicated server would have a payback period measured in minutes.
It depends on the business unit. Some don't have the ability to run a technology group to run a $10K dedicated server.
Learn from history, specifically, SQL. Or people who think they are too important to learn SQL aren't that important after all
If you want to stop out of control spend, have your analysts learn SQL. Avoid database systems that charge per query (like tinybird) and make damn certain your people know SQL if you do. Ignore and preferably fire people who mention things like “data lakes”.
Learn SQL ffs.