Scenario 1 - You leave "Pool Data Connections" unchecked in the Intraweb Application Wizard
In this scenario the wizard creates a ServerController, a UserSession but not a DataModule. You place your database, session and dataset components on the UserSession.
Whenever a new user connects to your website a new instance of the UserSession is created and a connection to the database is made. When the ServerController.SessionTimeOut expires due to user inactivity the UserSession is destroyed and that particular connection to the database is severed.
For 30 concurrent users this model will probably be fine for you and should guarantee that all database connections will be severed when the website is not in use.
Scenario 2 - You check "Pool Data Connections" in the Intraweb Application Wizard
As well as the ServerController and the UserSession the wizard will create an empty DataModule. You place your database, session and dataset components on the DataModule.
The ServerModule has a TIWDataModulePool component on it which has PoolCount property.
When your application starts it creates PoolCount instances of the DataModule each one of which makes a connection to the database. As your pages require database access they call LockDataModule and UnlockDataModule to temporarily make use of one of the DataModule instances from the pool.
When your application closes the DataModule instances in the pool are destroyed and their connections to the database are closed.
This model is appropriate when having an open database connection per user would exceed the capabilities of your database server. For just 30 users connecting to a FireBird database I don't believe it would be required.