Hacker Newsnew | past | comments | ask | show | jobs | submit | qaq's commentslogin

For me Grok finds legit bug that Fable and Astra miss so I always run it as part of code review

they were sold an idea the AGI is right around the corner so even a slight delay might be critical to secure the "win"

Google Cloud revenue grew 82% year-over-year I am guessing they gonna survive fine

It's still "only" 10-15% of Googles total revenue and less than 10% of it's profits. It's not nothing, but it's also not nearly as important as the dodgy ads business.

https://fortune.com/2026/04/29/google-earnings-cloud-ai/


dodgy ads business is not growing at 80% yoy

OK so it's not just me


Use cursor cli for grok pretty happy with it.


I mean, given Sam and Elon’s relationship, I don’t think anyone is surprised.


Why? All big and even medium tech companies have dev offices in EU and India. As example since it's much easier to deal with visas say in Ireland a lot of hiring was shifted to Irish offices.


Man I admire AWS marketing team for convincing people DynamoDB is a very good product.

100 items max per Transaction BatchGet 100 items, 16 MB max low write limits on same key Item size 400 KB max etc.


DynamoDB has basically two legitimate use-cases that I'm familiar with:

1. You're selling a system to a customer to use within their own AWS account, that you will have no access to, and it needs a transactional datastore (not just an object bucket) of some kind. The fact that it costs nothing by default (particularly valuable when the customer is trying to deploy a proof-of-concept), scales more-or-less perfectly without anybody touching it, requires zero day-to-day maintenance by you or the customer, and all it will ever ask is that you throw money at it, is very, very much a feature. One example I'm familiar with in the wild is Teleport: https://goteleport.com/docs/reference/deployment/backends/#d...

2. You have a huge OLTP workload that fits Dynamo's KV patterns (e.g. Amazon.com shopping carts, which is what it was originally built for). You don't care how much DynamoDB costs (in either dollars or engineering limitations) because any alternative would melt your face off if you even tried.

Most of the pain that comes from Dynamo is people who try to use it as a primary datastore in place of a relational database just to get the serverless pricing model. It's not worth giving up the flexibility on greenfield systems. It does become worth it to give up the flexibility when your system is mature and you don't have genuine flexibility anymore anyway.


Anyone trying to use a kv store for relational workloads is The same kind of person who uses a kv cache with durability features instead of a kv store. You can’t blame the tech for their mistakes.


Some of the largest, highest TPS, highest throughput systems in the world use DDB.

The constraints are what let this happen. Unconstraining it might make a better generalist product but part of what you're opting into with DDB is the dumb "put an item in get an item out semantics" and the other side is knowing that it will still work if that volume increases dramatically.


Which makes it a great product in a comparatively small niche, and a "meh" premature optimisation pretty much everywhere else. Except for right at the bottom end where it's a step up from a JSON file in an S3 bucket.


The reason it's good is because, although it is bad, you never have to worry about it in terms of maintenance, admin or scale. It's like lambda for databases.

For the same price, you can run a much more capable PSQL instance with way better features, but now you're on the hook for it being up 24/7.


They should really call it "data-structures as a service" rather than a database, really. Programming against it always reminds me of Leetcode problems, having to define your columns in a way to suit the very specific lookup patterns that they allow for.


I mean this reminds me of Firebase v1 and FoundationDB I think both of which have a favorable reputation for quality in both design and implementation. I do think there's something to be said for being forced to code against what operations are actually fast in your DB. Once it works you can be reasonably confident it will also be fast rather than the typical RDBMS experience of getting an abundance of rope with which to hang yourself with. You often won't find out until it's already load bearing that your query doesn't scale.


You do have to worry about scale with lambda though. It’s not super hard to hit a rate limit where warm up times start being a real problem.


Thanks, I don't really get any chance to seriously use or manage OLTP databases (mostly working with OLAP ones myself) so it is good to know about this. The 400KB limit is indeed very limiting -- I had to truncate some data because of that.

I wish I could get a role to work on OLTP databases. PostgreSQL seems to be a fascinating topic so that's on my plate.


Not just that once I hit my Fable limit I naturally experimented with other options and realized that 5.6 Sol + Grok 4.6 gives me same quality of results as Fable + 5.6 Sol so not really that reliant on Fable anymore.


and now 1000 sqft home in Compton is 600K


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: