Short answer: there is no guarantee of the ordering of events during startup and therefore you should look to using other methods such as retry loop in your DatabaseStart event when trying to connect to another database that is starting at the same time.

The longer answer:

Starting a database server is a complex sequence of operations but when it comes to starting the databases which have been specified on the command line all databases are scheduled to be started at the same time. "Scheduled" here means that a request is put into the queue for each database that is mentioned on the command line thus causing each database to be started asynchronously with respect to the other databases.

Starting up a database is also a very complex sequence of operations but it starts when a worker thread picks up the request that has been queued. After lots of checks and recovery (if needed) has been completed then provided no errors occurred the DatabaseStart event for the database will be executed.

So hopefully from the above you can see that the executing of the DatabaseStart event on each database is not dependent of the state of the other databases that are starting at the same time and therefore you are not guaranteed that (in your case) the second database will be up prior to the first database DatabaseStart event executing.

So let us now address the issue of the connection between the first and second database. If the connection attempt is made prior to the database being ready to accept connections then the connection attempt will likely fail. I say "likely" because if you are using TCP/IP then (depending on your connection string) there could be up to a ~5 second delay while the location of the remote server/database is being discovered (via UDP packets being sent out). This delay may be sufficient to let the second database get to the state that it can accept connections.... but there is no guarantee that it will be.