Comment by hobofan

Duckdb is already an aws offering

I could definitely imagine Java in better hands.

I can't think of many other languages/frameworks where one of the worst places to install it is from the primary sponsor/maintainer.

Java could be in better hands. Maybe will be, one day, when Oracle finally ends up fighting the organisational fire that has started in their debt pile.

Google is better but it's an incredibly low bar.

Amazon will drive these people to quit within a couple years over filling out MBRs and threats about how the MBR isn't good enough (MBR = monthly business report, pure bullshit theatre that drives the whole company mad 2/4 weeks every month).

Google would drive them to quit over a longer timeframe, with no threats or harrassment, just because every time they try to ship something cool, someone else has a reason not to do it and that kills you eventually.

To be fair, I suspect most of the core team is effectively rich after an acqu-hire.

If I had 5 million I’m going to retire and never code for money again.

I do want to make small video games though, make some music. Pay for a friend’s kids college.

I wouldn’t waste a single extra hour making more money. Usually the golden handcuffs fall off after a year or two. That’s why Heroku went to crap, all the core people left.

Google Maps is also an acquisition from more than 2 decades ago, by the way.

Youtube is another famous example.

Google had a better reputation. But these days I’m really not convinced they’re significantly better than Amazon.

Weirdly I’d put Microsoft above modern-Google, and that’s still a low bar.

What business model do MIT licensed projects even have? If you want to offer support contracts and actually make people use them, don't use MIT. You can't have you cake (accepting public contributions and free labor) and eat it (sole profiteering) too.

..a strategy valid in the good ol' days when a complete rewrite of the currently non-licenseable non-protectable underlying desings and ideas would not cost you 200$ on tokens to reimplement in a different or even in the same language.. maybe SW patents will be a thing soon .. and inadvertently become another nail in the coffin of FOSS and SW development in general, who knows

Not to mention Angular

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.

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.

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.

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.

For example, I would like to know how to calculate the charge of incremental export before I run one.

One blog says it is charged by the amount of change logs (but the official doc doesn't say so), which makes sense. But how do I estimate the amount? My hunch is: Put + Write + (1~100) * TransitWrite + Update + Delete + (1~25) * BatchWrite.

For anyone interested in the differences between dynamo (the early internal-only KV store described in this paper) and DynamoDB (The AWS service), Marc Brooker has an excellent writeup https://brooker.co.za/blog/2025/08/15/dynamo-dynamodb-dsql.h...

It is their previous one. I did read another paper about DynamoDB, but still there is not much details.

For example, I want to know how to calculate the charge of incremental export. One blog says it is charged by the amount of change logs (but the official doc doesn't say so), which makes sense. But how do I estimate the amount? My hunch is: Put + Write + (1~100) * TransitWrite + Update + Delete + (1~25) * BatchWrite.

Nothing to do with DynamoDB except the name.

This is massively different from DynamoDB.