Do non-PostgreSQL database softwares use roughly the same "structure" for communicating with them? Basically, I have developed a PostgreSQL-based application which &quot;in theory&quot; could have its database software swapped out, but probably would cause a million headaches if I actually attempted to. I'm trying to determine if the other SQL database softwares (I frankly don't care about non-SQL ones in the least, because they seem too different for me to bother with them in this life) have the following concepts:

&quot;hostname&quot;
&quot;port&quot;
&quot;username&quot;
&quot;password&quot;
&quot;handle database&quot; (such as &quot;postgres&quot;, which must be used to connect when there is no other database or when certain operations are to be done to the actual database)
&quot;database name&quot;

I guess I'm fairy sure already about all the points except for the 5th. The concept of a &quot;handle database&quot; seems like it might be PG-only. If such is the case, I'm not sure how I should handle that, but I'm awaiting your answers before I make a decision.
I have a good mind to just forget about ever supporting other database softwares, but the way my system is structured basically forces me to at least try to &quot;genericize&quot; the communication with the database with functions called &quot;database_&quot; rather than &quot;PostgreSQL_&quot;. (Even when the queries sent to these functions would only work on PG...)
Most client/servers DBMSes have parameters similar to those, and the handle database indeed is an unknown concept elsewhere. But they might need other parameters; the common way to handle is with a connection string (or URL) that encodes all those parameters, or with a generic list of keys/values.
And for databases that do not use a client/server architecture, it's even more different. If you do not need much concurrency and want to avoid having to install the DB server, you would be likely to choose SQLite, and then the only connection parameter is the database file name.