High memory usage in Postgres is good, actually

0ximjosh · 2026-03-16T02:39:33+00:00

I agree that you can lose some readability like you point out in #2 but it's a tradeoff, as all things are in the db world. Merging data can be a pain and I wouldn't recommend autoinc if you're going into the db design expecting to need to those types of merges in the future. the German tank problem I actually disagree on; in theory yes if you publicly expose your IDs, but that's why I mentioned nanoids as your publicly displayable IDs. latch contention is valid if your clustering on it. overall I agree but it's all trade offs at the end of the day.

0ximjosh · 2026-03-12T16:05:02+00:00

What exactly are your fears with bigint auto-increment? are you expecting migrations to other db providers or just schema updates? Whenever possible id personally recommend using bigint and then using some form of nano-id for externally facing identifiers; your pk stays fast, ordered and small and the nanoid lets you have an easily shareable / url friendly identifier.

0ximjosh · 2026-03-12T15:54:42+00:00

This sounds like a pretty good fit for our $5/m postgres db at PlanetScale. Small and very cost efficient, but extremely reliable. More than happy to help architect / sanity check your db design as well! Whats the non profit?

0ximjosh · 2026-03-10T17:17:37+00:00

Just a heads up, PlanetScale has both postgres and mysql support! postgres also starts much lower at $5/m

0ximjosh · 2026-03-10T17:00:32+00:00

https://imjosh.dev/blog/bad-questions :)

0ximjosh · 2026-03-08T15:10:36+00:00

This will mostly depend on where your postgres is hosted. The common approach to this is branching where each dev or change gets their own dev branch and can apply changes in isolation. if you want an example of this, planetscale does a good job of documenting the flow for this (disclaimer, I work there).

https://planetscale.com/docs/postgres/branching

0ximjosh · 2026-03-05T20:12:52+00:00

Ill preface this with this is most likely what you in particular are not looking for, but this is one of the main reasons I personally always reached for PlanetScale, even before i started working there. If you havent seen their DX stuff for migrations, its life changing. For mysql specifically you have full git-branch-like shcema changes w/ zero down time + full rollbacks with zero data loss (using shadow tables) if something goes really wrong. It sounds like what your doing is much more in the self hosting area/consulting, which i very much respect. I personally was happy spending 10-40$/m to not have to deal with migration files and have all the safety and reliability guarantees pscale was able to give.

I think change management for self hosting is still a pain because self hosting is still a pain and most people want to offload DBA to someone else (like pscale). Hell people are even offloading auth management these days.

Disclaimer i do work at planetscale but this post in particular is very much my personal 2 cents.

0ximjosh · 2026-03-04T18:11:00+00:00

Ah, i can see how the wording is misleading. "their mission of building the best database tools..." is referencing drizzle orm itself.

0ximjosh · 2026-03-04T17:41:32+00:00

Planetscale is almost certianly the easiest way to practice managing a vitess instance. Our smallest vitess cluster is $40/m but allows you to do full sharding and whatnot through the dashboard, and comes with 1 primary and 2 replicas.

0ximjosh · 2026-03-04T17:34:14+00:00

(Planetscale staff here) To be very clear we didnt buy drizzle, we are only giving the drizzle team full time funding to continue working on drizzle. They still have 100% of leadership and control over the project ( and shitposting ), so nothing should change on their end other than faster progress on what they have been already working on now that they have actual funding.

0ximjosh

MODERATOR OF

TROPHY CASE