Is it bad practice to launch more than 100 sql statements at once? I have PHP code that is meant to updating the billing status of someone. I only want it to update if the bill has been successfully created and therefore I think a possible solution would be to perform an update after each bill. However, this means that I will end up performing over 100 queries in a very short amount of time. 

As I am unfamiliar with database management in general I want to pose this question here.

Perhaps there is a query cache limit that I don't know of or perhaps this is a really bad practice in the database community such that I should be expelled for even proposing this.

I could make a work around where I just collect all of the successfully generated bills and then apply updates to those people, but then I would still need a whole lot of "WHERE" clauses to update only those customers.

Suggestions, ideas, concerns, quips?

I am using postgres for this database, but I would prefer answers that are not specific to Postgres as this database has been migrated before.
It depends on how your queries are organised. Important is that you use transactions. The first step in the transaction would be the creation of the bill and the next step in the transaction would be the update of the billing status.
Both need to succeed or both need to fail. If the second step fails, the first step will also be rolled back.
If this is some kind of a batch process, try to work in sets instead of on single rows. If you can process the work in 1 or 2 calls it will be a lot faster than issuing 100 or 200 calls for the same amount f work. With a lot I really mean a lot. If the code is correct easily a magnitude of 100 faster.