3 ms·

While the indexes /may/ be pretty well thought out. That doesn’t mean that they are useful. Indexes don’t work the same between SQLite and PostgreSQL so a 1:1

While the indexes /may/ be pretty well thought out. That doesn’t mean that they are useful. 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.

pphysch 4y ago
> 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.
- jeffdn 4y ago
  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.
  - Pv9KKy3 4y ago
    I use and prefer varchar(1000) personally, extremely easy to change in the future if needed.
  - pphysch 4y ago
    > 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!
trollied 4y ago
There are also a shitload more indexing options available to you in Postgres.

pphysch 4y ago

> 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.

jeffdn 4y ago
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.
- Pv9KKy3 4y ago
  I use and prefer varchar(1000) personally, extremely easy to change in the future if needed.
- pphysch 4y ago
  > 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!

trollied 4y ago

There are also a shitload more indexing options available to you in Postgres.