One big difference between REALSQLDatabase and a database server is that database servers handle record locking. When one user wants to edit a record, the record can be locked by the database server so that others users can't edit it. REALSQLDatabase has no facility for that. You could create your own system by storing an array of objects either globally on the app class (or in a module) or as a property of each session where each session would keep track of which record or records it is editing.
REALSQLDatabase is based on SQLite. SQLite allows for any number of users to read the database at the same time but allows only one user to write to the database at a time. If a user attempts to write to the database at the same time another user is doing so, an error will be generated. You can determine this by checking the Error property of your REALSQLDatabase object immediately after doing anything that updates the database. Because of SQLite, REALSQLDatabase is very fast at updating records and in our limited testing, we could not get it to do two updates at the same time and produce an error.
Currently, when you add a database connection to your web project the connection is handled globally rather than by session. If your app's database access is user-driven, as in a case where the user initiates a query for example, then you should connect to your database via code so that you can store the database reference on the session class. With this technique, each session will make a separate connection to the database and SQLite can manage things properly (as best it can). Before we ship our web framework, we will likely change this internally so that database connections added to the project will automatically be session-based.
So depending on the nature of your application and the number of users that would need to write to the database at the same time, REALSQLDatabase very well may work for you. Just keep in mind that you will want to test for an error after any update to the database (which you should be doing anyway) and that if you need some kind of record locking, you'll have to implement your own system for that.
If you have a traditional database-oriented application, you will be better served (no pun intended) by using a traditional database server.