Live data from Hacker News

The startup's Postgres survival guide

hatchet.run

21–30 of 255 posts

Re: The startup's Postgres survival guide

#21
I did a search in that post for "function", zero results.

Unimpressive. Not even the most cursory of discussion of stored functions ?

Given that many startup's Postgres instances will no doubt be backing some web-ui or app that takes untrusted input, surely they could have at least had a brief discussion about how stored functions can help against SQL injection attacks ?

Not only that but it means you have to think, it prevents devs just writing their own random queries.

Also zero mention of `text`, which is highly encouraged in Postgres instead of the silly old `varchar(255)`

Re: The startup's Postgres survival guide

#22

I did a search in that post for "function", zero results. Unimpressive. Not even the most cursory of discussion of stored functions ? Given that many startup's Postgres instances will no doubt be backing some web-ui or app that takes untrusted input, surely they could have at least had a brief discussion about how stored functions can help against SQL injection attacks ? Not only that but it means you have to think,…

The last thing a startup has time to do is stored functions

And if they "do have", they're not spending enough time with their service-market match

Re: The startup's Postgres survival guide

#23
Some comments and corrections:

* Use uuidv7 not uuid in general (typically v4)

* in addition to minimizing locked records, make sure your locks are ordered deterministically across all queries (eg by id asc, always) or you’ll deadlock (but postgres has a really good deadlock detector so you’ll more likely just error out if you’re lucky)

* always use explain (generic_plan) to be able to a) copy-and-paste your queries with placeholders for parameters as-is, b) see how your query will actually be optimized when Postgres doesn’t have visibility into the specific parameter values

* use set seqscan = off when testing your query plans esp when tables are empty or nearly so so you can see if indexes will be used when seq scans become less cheap

* everyone defaults to btree indexes which are heavy and increase index bloat. Consider using a hash index instead if you just need to look up by column/id but not sort or get values greater/lesser than a param. You can’t create unique hash indexes but you can create exclude using hash constraints for the same effect (except no multicolumn unique index support)

* learn about GIN (and GIST) indexes. They can speed up common queries without needing new syntax, something people coming from MySQL might not expect to be possible; i.e. you can use them to speed up Plain Jane like ‘%foo%’ queries without switching to FTS.

Re: The startup's Postgres survival guide

#24

I did a search in that post for "function", zero results. Unimpressive. Not even the most cursory of discussion of stored functions ? Given that many startup's Postgres instances will no doubt be backing some web-ui or app that takes untrusted input, surely they could have at least had a brief discussion about how stored functions can help against SQL injection attacks ? Not only that but it means you have to think,…

The last thing a startup has time to do is stored functions And if they "do have", they're not spending enough time with their service-market match

> The last thing a startup has time to do is stored functions

If they have time to write SQL queries, they have time to write stored functions.

Its really not that difficult and it certainly does not take a substantial amount of time.

Re: The startup's Postgres survival guide

#27
post #3

Should one of the first things you do with a database not be to have a backup strategy? I understand that HA would be a "nice to have" when first starting out, but surly if you have a production db, a backup and restore plan should be on a survival guide? Neither appear to be mentioned here. What do you all use for your pg backups? Is Barman ( https://pgbarman.org/ ) still the way many do it? (I haven't deployed a ne…

There’s no need to get all complicated and fancy or introduce more dependencies. For most people, a cron job calling pg_dump_all piped to zstd and copying the output to s3/ftp/whatever is plenty good enough. Obviously past a certain point carting around full backups becomes time/dollar prohibitive, but this can take you very far.

If you can afford to lose the data created between backups, sure.

Re: The startup's Postgres survival guide

#28

Earlier quoted context omitted.

The last thing a startup has time to do is stored functions And if they "do have", they're not spending enough time with their service-market match

> The last thing a startup has time to do is stored functions If they have time to write SQL queries, they have time to write stored functions. Its really not that difficult and it certainly does not take a substantial amount of time.

No

They have the time to write SQL queries in their code

They don't have time to (or better, shouldn't) materialize them as a stored function in the DB

"Oh but your CI/CD should automatically..." Let me stop right there

The time they spend with this can be better used to ship and to improve their SW to customers, not with yak shaving

Re: The startup's Postgres survival guide

#29

Lately I been questioning whether it’s actually a good idea to pool connections. Don’t your in the risk of leaking privileges or information from other requests?

Typically no.

In most (all?) cases the pooler manages one pool per database user, so even if there was something leaking, it would not be anything that the database user couldn't access anyway.

But if you are paranoid, you can configure the pooler to run "RESET ALL", "RESET ROLE", "RESET SESSION AUTHORIZATION" and "ROLLBACK" before handing out a connection.

Re: The startup's Postgres survival guide

#30

I did a search in that post for "function", zero results. Unimpressive. Not even the most cursory of discussion of stored functions ? Given that many startup's Postgres instances will no doubt be backing some web-ui or app that takes untrusted input, surely they could have at least had a brief discussion about how stored functions can help against SQL injection attacks ? Not only that but it means you have to think,…

> devs just writing their own random queries.

I've spent a lot of time writing my own random queries. I don't know that I've ever written a stored function.

Post reply on HN