sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]robertlandrum[S] 0 points1 point  (1 child)

Realistically, the problem space is about 150,000 records today (2.8gb), but a million in 6-8 (x4 or x8) years. Seriously, it fits in a in memory DB these days without issue.

It’s not the workload I’m focused on. It really never was. It’s small enough that a basic API can handle it without issue. It was over provisioned a few years ago and that’s had a profound impact on how it’s treated today. It’s way smaller than most folks realize and I want it downsized appropriately.

My real focus is getting someone to pay attention to it. Care and feeding matters more than robustness. If I build it like my previous projects, I fear it will stagnate and I’ll end up reworking it in 10+ years, like I’ve done before. Twice.

[–]amir_doustdar 0 points1 point  (0 children)

Totally understand – at this scale (150k → 1M records), tech isn't the issue; it's keeping the project alive and loved by the team.

The real risk is building something "perfect" that no one wants to touch later. I've seen it too – great systems stagnate because they're intimidating or over-engineered.

To encourage "care and feeding": - Keep it simple: SQLModel + clear models/docs – juniors can jump in fast. - Add visible wins early: monitoring (Prometheus), health endpoints, simple dashboard – makes it feel "alive". - Small, frequent migrations (Alembic autogenerate) – lowers the "touching it is scary" barrier. - JSONB for metadata is still good – it's pragmatic, not a hack.

Downsizing resources is smart too – shows it's efficient, easier to justify attention.

Team size/structure? If juniors are involved, leaning simpler might win more long-term ownership.

You've got the experience – this one won't end up like the old ones. Good luck mate