Hacker News Reader

If CockroachDB was fitting your use case the best, you should have a look at YugabyteDB. It does triggers, stored procedures, extensions, almost everything. Some alter table features aren’t working yet but it’s getting there.

Not associated with the company but a very happy user.

Bonus point: YugabyteDB is full Apache 2-licensed so you can roll your own.

Just took a look and it seems pretty nice!

But found their pricing page (which was very hard to find other than the generic "contact sales" page) and it seems the starting price is 360 USD/month, that's not something we're comfortable with right now.

USD 0.25/vCPU/hour, minimum 2 vCPU = 0.25*2*24*30 = 360

https://www.yugabyte.com/yugabytedb-managed-standard-price-l...

> Fly.io price scaling is too aggressive 6$ -> 33 -> 154 -> 1000s a month and no free tier that I could find.

Fly has a general purpose free tier of 3 of their smallest instances. You can use that to run their 2-node Postgres cluster plus an app server.

The pricing you pulled is examples of various compute + storage configurations, not the exhaustive list of options. It should look like $4 (or free tier) -> $11 -> $21 -> $62 -> $82 ... + storage, since it's just 2x their VM price (for the two nodes) + any storage above free tier.

Last I used them (last year) their postgres offering, even scaled up to larger nodes, was significantly slower than the cheapest DO offering. I filed a few issues but haven’t checked back since.

Ah nice!

So the prices I mentioned where just example configuration. That's pretty cool then, specially with that free tier.

Will put fly.io back on the list and do some benchmarking in the future.

Thanks a lot!

Curious why a free tier is so important?

I think a FT encourages bad behaviors on both sides. I don't think pricing should be linear at all. But even for development, one is using resources, but most of the time they can be minuscule for individual devs.

Aside from production reliability, Postgres is one of the easiest things to get running on a VM and runs fine on a 5$ a month instance.

Free tier, like all things, is pretty bad if misused.

The reason we want a free tier is to try things out before we can actually commit to something. We don't know if what we are doing is actually gonna make money and sometimes we go a few months without working on it. So it's kind of a pain to pay for something we don't use.

That's why serverless is also nice to have on our current stage, things can just scale to 0 and there's no wasting of resource.

> running on a VM and runs fine on a 5$ a month instance

Easier said than done, unfortunately.

"Aurora serverless v2 is only for aws internal access and we are using gcp." You can have public access to serverless v2. I'm using it with retool for example. That said I moved a Postgres DB to Aurora, the process was hilarious in how crazy it was. Also they haven't implemented scaling to 0 yet!!!! And the minimum 0.5 Compute unites are actually pretty expensive.

Nice point about the minimum 0.5 ACU, forgot about that one. From what I've read 0.5 on v2 is the same price as 1 on v1, which seems pretty dumb coming from aws.

Could you elaborate more on this:

> You can have public access to serverless v2

Because the docs mention the following:

> You can’t give an Aurora Serverless DB cluster a public IP address; you can only access it from within a VPC based on the Amazon VPC service.

Potentially I could setup an RDS proxy or vpn inside the vpc and give that public access, but that seems a bit of a roundabout way of handling this. https://aws.amazon.com/blogs/database/best-practices-for-wor...

I can 100% confirm public access works :)

Could you elaborate on how you got it to work without a public IP?

Its a completely crazy process but it works roughly like this: (going from RDS Postgres on 12.6 to Aurora Serverless V2)

1. You create a snapshot of your original db

2. You update that snapshot to 13.4 (NOT 13.6!!)

3. You have to use the AWS CLI (because the online migrate doesn't work) to create a cluster from the snapshot

4. Remember this cluster is 13.4, serverless only works with 13.6, so we have to upgrade it later again

5. However we can only upgrade it when there is a running system

6. so we create a non-serverless aurora instance. Most instance types returned an error but using t3.medium worked, you can create that with public access.

7. when they are both created you can already try to ping your DB (it should work)

8. upgrade to 13.6

9. Now you are able to change the DB instance type to serverless

Edit: BTW I am available for hire as an external contractor for this kind of stuff ;)

AlloyDB is free during its preview phase (not sure how long that is).

https://cloud.google.com/alloydb/pricing#fair-usage-limits

Read gcp's policy and they say preview periods can last around 6 months, and I'm not sure when alloydb preview started.

But even if there's a free period, it'd be complicated to develop stuff around the DB for free, just to turn into 100s of dollars after 6 months, that's not something we want to see happening. So an indefinite free tier with limited resources would be better. Like aws lambda 1M or firebase function 2M request free tier.

Did you look at Crunchy Bridge? Not sure if they support that use case.

Took a look just now and they start at 35/month. They have some nice points around support, backup and disaster recovery. But if that's the starting point, I'd prefer something like digitalocean that has a similar product offer starting at 15$.

Thanks for the tip though!