21–30 of 72 posts
Earlier quoted context omitted.
I always wonder, who looks at their pricing model and decides "Paying multiple dollars to query on a few GB of data sounds reasonable"?
Seriously? A $10k dedicated server would have a payback period measured in minutes.
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?
Quoted post unavailable.
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"
I'm really curious how people use these types of platforms in practice. It seems really easy to screw yourself over when you're "expirementing". The advice seems really obvious, but I'm sure I'd absent mindedly do a super naive query at some point and potentially cost my employer a lot of money. I worked on a system to capture the production test data in a semiconductor company. We had trillions of rows and terabytes…
So this product is not only expensive, but I have to think of the execution plan myself? Or I am wrong and modern dbs don't do that?
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”.
Also it’s not unreasonable to see people spending $10K+ a day in Snowflake because bad practices just like this.
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”.
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.
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”.
Wow, I've previously had exactly same feelings about couple of people from whom I heard "data lakes".
I remember when I studied databases in college, the execution plan took care of what to do first: join, filters, etc (I remember doing excercises with paper and pen where I got a query, a few tables, and I had to build the optimal execution tree). So this product is not only expensive, but I have to think of the execution plan myself? Or I am wrong and modern dbs don't do that?
Query 1 -> join Table A with Table B, both have 1M records
Query 2 -> Filter Table A to 10k records, then join Table A with Table B (1M records)
I would expect Query 2 to execute faster - I don't think the exec plan would've optimized Query 1 equivalently.
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”.
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.