> typically in PostgreSQL you just use text type and not impose any length restrictions unless absolutely necessary.
There was a horror story posted on here a while back about some old API causing an outage because there happened to be a random text field that a user was effectively using as an S3 bucket. Their conclusion was to always set a sane length constraint (even if very large, say 1MiB for the smallest fields) on field sizes.
Hyrum's Law. Yes user input validation, blah blah, but that is infinitely more surface area than having a sane (or absurdly large) limit by default.
Right, but use a check constraint and not a data type constraint (i.e. `varchar(x)`).
That sounds more like a code review issue -- `blob` would've been an appropriate storage type in that case.
> That sounds more like a code review issue -- `blob` would've been an appropriate storage type in that case.
No, it was supposed to be a short text field. Not an infinite storage endpoint!
I use and prefer varchar(1000) personally, extremely easy to change in the future if needed.
Indexes don’t work the same between SQLite and PostgreSQL so a 1:1 transition between the two databases on indexes probably isn’t going to yield the best results.
For example UUIDs were stored incorrectly in PostgreSQL.
SQLite does not enforce varchar lengths, and typically in PostgreSQL you just use text type and not impose any length restrictions unless absolutely necessary.
PostgreSQL can use multiple indexes in a single query which may help with the 2gb ram limits.
PostgreSQL supports partitioning which could help with the range queries.
All I’m saying is that I believe the performance you get from SQLite imo could be better, and the performance from PostgreSQL a lot better.