While I do love Postgres and use it daily on AWS and Google Cloud, I will add that the managed Postgres on Google Cloud is a mess in some areas. For example they use some EOL extensions outdated for 10+ years (a specific example is GEOS) and refuse to update it and give no control for you to upgrade it either.

I wonder where things will stand in 10 years from now. Will many orgs still be consuming vanilla Postgres, or will most workloads have shifted to ~proprietary implementations behind cloud services like "Aurora PostgreSQL Limitless Database" and "Google AlloyDB for PostgreSQL" due to unrivalled price-performance? In other words, can progress in OSS Postgres keep up with cloud economics or will things devolve into an even messier ecosystem centred purely around the wire protocol and SQL dialect?

Databases seem to grow much slower than other assets, so maybe this price advantage just won't be worth the vendor lockin. Hell my current extremely valuable postgres database worth literally millions of dollars is about thirteen gigs and could be hosted on my mac mini if I really wanted to. Still, the managed hosting is worth it—only without vendor lockin!

DBMS (and DBAs) tend to be more conservative, so extensions and implementations diverge much more slowly than, say, js.

There's also the incoming business argument in favor of not diverging too far from baseline.

If I'm AWS/Azure/GCP trying to attract a customer from a competitor service, 'completely rewrite your app to be able to use us' isn't a compelling pitch.

MS SQL Server and Oracle have different incentives, but the cloud services would probably prefer portability and decreased maintenance / fork support load.

Can you elaborate on a few things with regards to your pricing:

* What does "$0.05 / gigabyte transferred" mean exactly. Transferred outside of AWS or accessed as in read and written data?

* "$0.20/GiB-mo of high-speed cache" – how is the high-speed cache amount computed?

Sure, and we have more details on pricing here which may answer your questions: https://docs.regattastorage.com/details/pricing

We need to update the home page with these details, but $0.05 is only charged on transfer between Regatta and S3. We calculate your cache usage minutely and tally it into a monthly usage amount that we then bill for.

Thanks for clearing that up. Few followup questions:

You don't actually directly charge for storage itself, so I assume this a "bring your own s3 bucket" type of deal, correct?

How long does data, that is no longer being accessed sit in the cache and count towards billing?

As for availability, are you in the process or do you have plans to also support Google Cloud?

> You don't actually directly charge for storage itself, so I assume this a "bring your own s3 bucket" type of deal, correct?

That's correct -- we store data in the customer S3 bucket.

> How long does data, that is no longer being accessed sit in the cache and count towards billing?

We keep data in the cache for up to 1 hour after you've stopped accessing it.

> As for availability, are you in the process or do you have plans to also support Google Cloud?

We have plans to support Google Cloud. If you're interested in using us from GCP, I'd recommend setting up some time to chat (either use the website or email me at hleath [at] regattastorage.com). We are prioritizing where we launch our infrastructure next based on customer demand.

Plus 1 for GCP. Cant wait to try it out.

I might just take you up on that.

FlexFS kicks ass. I benchmarked it for our data storage and processing layers in value.space (satellite data processing and analysis) and we will most likely migrate to FlexFS in the near future.

Out of curiosity, why did you choose EFS, it's insanely expensive at even modest scales?

You absolutely can and it is true.

> So, the bridge was under stress and moving(breaking off?) slowly by few mm each year causing the eventual collapse?

This is what it looks like from the data. The key here is "diverging paths", which means different parts of the bridge were moving in different directions, putting strain on it.

> which means different parts of the bridge were moving in different directions, putting strain on it.

Thanks! But how was this not noticed[1] by the maintenance and renovation works? I would assume, such patterns should show visible cracks or some symptoms beforehand.

[1] I know that, for a huge structure, a few mm movement is tough to even notice without major equipment and monitoring, but still I believe inspections are done frequently for structural changes and damages.

Not sure. Perhaps a further investigation by the authorities will reveal the reason.

That is the goal.

So this is done via InSAR (https://en.wikipedia.org/wiki/Interferometric_synthetic-aper...), leveraging ESA satellite data. Not sure on the buzzword bingo there.

It is an after the fact survey done on historical satellite data. More data can be found here: https://newsletter.value.space/p/bridge-collapse-germany-aty...

I was gonna say... When your system is large enough to run into this specific performance bottleneck, pop a bottle and celebrate, you are making enough money to solve that problem.

While knowing this information is useful, most services fail in different domains and problems way before you reach that point. I'm not sure people really comprehend how hard you can hit a single machine before you need to distribute a workload.

Regarding Baldur's Gate 3 on M1 Pro, can confirm, the performance is just amazing.

Indeed, I'm getting better performance than my 3 year old Windows machine with a 2070 gtx. I wasn't expecting gaming laptop performance from a mac, but I was pleasantly surprised.