Small. Fast. Reliable.
Choose any three.

The above misses the whole point. Schema's are not "users".

Often, people don't use database schemas to their full advantage. By schema, I'm not talking about the design details of tables and columns. Standard ANSI SQL defines a schema to be a collection of database elements. Earlier versions of MS SQL Server didn't support the schema, but had the user in the syntax. For example: dbo.TableName

Starting with SQL Server 2005, SQL Server now supports Server.Database.Schema.Table.

Many times, people separate logically grouped tables into their own databases. Architecturally, this is non ideal. One bad thing about this is that database names are likely to become hard coded. For example, USE [MyDB]


This is bad because now there can't be multiple instances of the system on one server. Normally, one can simply create multiple databases on the same server. For example, a database for dev, test, stage, demo, etc. With multiple databases and hard coded db names, each instance of the application must be on a different server.

A better approach is to have multiple different schemas in the same database. This results in

SELECT C FROM MySchema.Table

So, SQLLite should support schemas, not because of the server issue, which is unique to MS SQL server, but because it helps separate logical groupings of tables.