[gjsman-1000]

> Except for some basic wire compatibility with the postgres protocol, I'd hardly call this a "database", and more a key-value store.

Hopefully that keeps the pricing reasonable. :)

But seriously, for a smaller CRUD app, this could be sufficient, even "magical," if the price is right. For my part though, the lack of multiple databases per cluster puts multi-tenant systems completely off the table. Now that you mention it, I almost wonder if this is a giant hack on top of Valkey/Redis...

[Edwinr95]

But a smaller CRUD app wouldn't need "virtually unlimited scale". I'm very curious what their target audience is.

[gjsman-1000]

I don't know, I manage a PHP app with about 10K users. If it doesn't cost much more, just paying to have the peace of mind that I never need to think about it again as my app grows, would not be a bad trade. This is assuming, of course, that the price is not extortionate.

[funcDropShadow]

In case it scales to Facebook's scale. Better safe than sorry.

[happymellon]

I work with a lot of financial services applications, and they are most definitely in the "simple CRUD" with regards to the database realm, but with extremely high throughput and multiregional.

Having it be Postgres compatible is the big selling point.

Who else would use it? Not sure, gaming perhaps?

[nilamo]

Possibly a game server? Between matchmaking, leaderboards, achievements, you'll never be updating 10k rows at once...

[everfrustrated]

>the lack of multiple databases per cluster

I don't think that will matter. This feels much more like DynamoDB where you're charged for GB used/stored and no infra cost, so no reason to nest databases

[Edwinr95]

Isolation can be quite important. I work with a micro services architecture, where we assign a database per service.

That makes it very easy to manage access to sensitive data.

[adobrawy]

You do not need logical database isolation if you have even stronger isolation with virtual clusters. The pricing and quota will be important factor for that use case.