mebcitto

Perhaps pure pgrx extensions would make sense as a first target?

Does it support the extension ecosystem? Or would extensions need to be rewritten as well?

Not sure it’s so simple. I think close to 100% of new ambitious projects are going to leverage AI at least to some degree. I know a couple that have strict no-AI policies (e.g. Zig), but it’s a tiny minority i think.

So how much AI usage does it make it an “AI rewrite”?

Unfortunately there is currently an issue in pnpm that makes `minimumReleaseAge` difficult: https://github.com/pnpm/pnpm/issues/11068

That might be opus 4.7 behaviour because I also get that all the time in the past few weeks. Also complex code base, but likely an order of magnitude simpler than yours.

This rings true to me. Rust is great but in environments where you need a lot of unsafe anyway, it’s still not memory safe, and adds complexity otherwise.

That explains why `sync` and `worker` have so similar results in almost all runs. The benchmarks from Tomas Vondra (https://vondra.me/posts/tuning-aio-in-postgresql-18/) showed some significant differences.

Yeah, I don't think "fixing" is really the right term here, since this brings a different set of tradeoffs. You don't leak timestamps, you get ok page locality, but you lose the ability to sort by the IDs. I do see how this might be a good choice for a general PK default (i.e. by default, don't leak stuff).

It's Postgres specific but there is https://github.com/xataio/pgroll which takes the automation a step further.

This is very interesting, thanks for offering to answer questions. I'm curious of two things:

* Are you also considering going the Postgres extension route, like Citus? It is after all the best attempt at sharding Postgres so far.

* If you are willing to share, why not doing this from inside Planetscale? I assume it was at least considered over the years.

Other relevant talks/blogs that I found really useful for understanding Postgres locks are:

* Unlocking the Postgres Lock Manager by Bruce Momjian: https://momjian.us/main/writings/pgsql/locking.pdf

* Anatomy of table-level locks by Gulcin Yildirim Jelinek: https://xata.io/blog/anatomy-of-locks

From the newish Go-based Postgres CDC tools, I know about:

* pgstream: https://github.com/xataio/pgstream

* pg_flo: https://github.com/pgflo/pg_flo

Are there others? Each of them has slightly different angles and messaging, but it is interesting to see.

I assume it's not that kind of ban, but more like he'll recommend his students to avoid the company.

A couple of spicy things:

> OtterTune. Dana, Bohan, and I worked on this research project and startup for almost a decade. And now it is dead. I am disappointed at how a particular company treated us at the end, so they are forever banned from recruiting CMU-DB students. They know who they are and what they did.

Ouch.

> Lastly, I want to give a shout-out to ByteBase for their article Database Tools in 2024: A Year in Review. In previous years, they emailed me asking for permission to translate my end-of-year database articles into Chinese for their blog. This year, they could not wait for me to finish writing this one, so they jocked my flow and wrote their own off-brand article with the same title and premise.

Also sounds like he's preparing a new company:

> I hope to announce our next start-up soon (hint: it’s about databases).

Georgescu's voters don't see themselves as pro-Russian. They think of themselves as "patriots", anti-LGBT, and anti-establishment. They also think that we are helping Ukraine too much, at the expense of domestic issues.

These are the messages that were used on TikTok, an open pro-Russia message would have been buried quickly.

If there is anyone from Neon watching this thread, is there a way to suggest updates to the pgversions website? It currently pins Xata to 15.5, which is true for the shared cluster environment depending on the region, but one can start dedicated clusters up to 16.4 at the moment.

I'm curious how the Essential plans work, given that Aurora pricing starts higher than that in monthly costs. It is probably databases in a shared multi-tenant Aurora instance, and then the single-tenant plans that are currently in pilot give you the full Aurora instance. That also explains some of the limitations and the low connection limits.

There is a monthly "Who's hiring" thread that might be better for posting this. Latest is this one: https://news.ycombinator.com/item?id=36573871

To give an example from an employer side, we do remote but we restrict roughly to the EU countries and the east-coast of the US (we do exceptions but only in really exceptional cases). We are incorporated in the US and use Deel for the other countries. There are two reasons we restrict like this: one is that we know that working across timezones gets difficult if there is almost no time overlap between business hours. And the second is that, even if Deel makes it easy to hire in a lot of countries, that's not everything. They don't cover, for example, stock options, and you need to respect the laws in that country that you have no idea of, meaning in practice that you'll spend quite a bit on lawyers to evaluate risks. For a single employee, it's usually not worth it.

Neon price is listed as per hour, instead of per month like the others :)

While you're not necessarily missing something, it's worth pointing out that usually storage costs don't dominate the bill, the compute costs are usually higher. But with the PlanetScale storage price being more then 10x the price of the other, it's definitely something to keep in mind, and it can dominate the bill.

I kind of have a thing for DBaaS pricing, and that table with the comparison with RDS looked suspicious to me because it doesn't specify the exact instance type used on the AWS side. ~~I think it should be `db.r6g.xlarge` because it has 4 vCPUs and 32 GB RAM. That is $0.43/h, so $0.43 * 730 = $313 / month. They have one primary and 2 replicas, so 313 x 3 = $940. It doesn't quite fit, so maybe that's not the instance type they chose, but indeed it seems cheaper.~~ But that doesn't take into account reserved instances, which can lower the price on the RDS side.

Edit: Looking again, I think the instance used for comparison is `db.r6gd.xlarge` from the Multi AZ-deployments (two standbys) list. That is $1.445/h, so $1054 / month. The difference could be for storage and I/O.

However, the PS Scaler Pro is $1.5 / GB, which is quite a lot. General purpose storage in AWS is only $0.115. The comparison table uses 10 GB only, but if the DB size is 1 TB, then RDS would be a lot cheaper?

Please correct me if I got something wrong, I'm sure there's stuff I'm missing.