Live data from Hacker News

Open Source Durable Objects for Postgres

solidobjects.dev

11–20 of 20 posts

Re: Open Source Durable Objects for Postgres

#11
> Pricing you cannot predict. Every operation is metered. One runaway alarm loop billed a pre-launch developer $34,000 in eight days, with no users and no warning.

It's amazing that we still lack the ability to set a hard cost cap on a lot of cloud services/API, as the consumer you usually have a rough idea of what something is going to cost (I say rough because pricing out AWS is always fun) and an idea of what the lower bound "oh shit that isn't right" limit should be, so why can we not set that.

You shouldn't be getting an unexpected $34K bill (unless it's within variance and you are running a very large system).

Cynically the opaqueness of this stuff has to be by design/intention at this point.

Re: Open Source Durable Objects for Postgres

#12
post #10
post #5

I don't know if it is ai generated or at the opposite hand written a little bit fast but I find this article very hard to read despite the concepts in it being simple.

The article is 1000% ai slop

Hard disagree there. I still don't know what the article is about if I'm being honest, but it doesn't bear the markings of being generated.

Re: Open Source Durable Objects for Postgres

#13

Author here. celld and workerd give you Durable Objects if you run another daemon. This is a library your app loads, with state stored in the SQL database you already have (Postgres, MySQL and SQLite supported). No daemon required, no new infrastructure and monitoring, no broker, and no vendor account. Pre-1.0, MIT, TypeScript, in browser (with WASM SQLite), and Ruby too. Happy to answer anything.

Please don't submit AI-generated articles.

Re: Open Source Durable Objects for Postgres

#14

> Pricing you cannot predict. Every operation is metered. One runaway alarm loop billed a pre-launch developer $34,000 in eight days, with no users and no warning. It's amazing that we still lack the ability to set a hard cost cap on a lot of cloud services/API, as the consumer you usually have a rough idea of what something is going to cost (I say rough because pricing out AWS is always fun) and an idea of what the…

Especially when Google and co tells you that they can bill by the second.

I do not own a hyperscaler account as a private person and will never do, the financial risk is too high even IF the support will swift it away.

Re: Open Source Durable Objects for Postgres

#15
post #10
post #5

I don't know if it is ai generated or at the opposite hand written a little bit fast but I find this article very hard to read despite the concepts in it being simple.

The article is 1000% ai slop

AI, but I'm not sure about "slop". There is actual content in there, for all it's written by an LLM.

Re: Open Source Durable Objects for Postgres

#18
post #14

> Pricing you cannot predict. Every operation is metered. One runaway alarm loop billed a pre-launch developer $34,000 in eight days, with no users and no warning. It's amazing that we still lack the ability to set a hard cost cap on a lot of cloud services/API, as the consumer you usually have a rough idea of what something is going to cost (I say rough because pricing out AWS is always fun) and an idea of what the…

Especially when Google and co tells you that they can bill by the second. I do not own a hyperscaler account as a private person and will never do, the financial risk is too high even IF the support will swift it away.

It is perhaps more accurate to say that they can meter by the second, but the billing calculation is a trailing activity.

Re: Open Source Durable Objects for Postgres

#19

> Pricing you cannot predict. Every operation is metered. One runaway alarm loop billed a pre-launch developer $34,000 in eight days, with no users and no warning. It's amazing that we still lack the ability to set a hard cost cap on a lot of cloud services/API, as the consumer you usually have a rough idea of what something is going to cost (I say rough because pricing out AWS is always fun) and an idea of what the…

>as the consumer

This is where this discrepancy occurs. AWS (etc.) aren't targeting "consumers," they're targeting enterprises. Enterprises want to use these services with minimal interference and overhead. They'll build out whatever features they need as they need them. It's the same thing with any other utility service: a factory isn't interested in having the electric company or water company shut off their services if their usage spikes. They'll manage their usage (and potential overages) in whatever way is specifically suitable for them.

Consumers have plenty of options to prevent such situations. Hell, AWS even offers Lightsail which is the consumer-friendly version of their services which is designed to be simple with a flat rate cost (including options of object storage).

If a consumer decides to tap into enterprise-grade services and ends up getting burned as a result, then I'm blaming the consumer rather than the provider of those services. These dynamics are all pretty clear and easy to understand (and even mitigate, with enough effort), so I don't see how you can claim they are "opaque" unless you're the kind of consumer who feels every company should dumb down their products to cater to the lowest common denominator.

Re: Open Source Durable Objects for Postgres

#20

> Pricing you cannot predict. Every operation is metered. One runaway alarm loop billed a pre-launch developer $34,000 in eight days, with no users and no warning. It's amazing that we still lack the ability to set a hard cost cap on a lot of cloud services/API, as the consumer you usually have a rough idea of what something is going to cost (I say rough because pricing out AWS is always fun) and an idea of what the…

What does a "hard cap" do then? Delete all your resources? Because even stopped instances or unused volumes cost you.

Although I admit, there should be spend warnings.

Post reply on HN