If you keep the default
search_path and use the default schema
public (automatically), you don't have to bother with schemas at all.
But if your database grows, chances are you will happily make use of them to organize objects and privileges. By setting the
search_path per user / database / session / ... you can manage schemas precedence any way you want. I have assembled a couple of ways to do this in this related answer on SO.
Schemas are much like directories in the file system:
If you don't schema-qualify an object name (
myschema.mytable), the first schema in your
search_path is assumed when creating objects. That's like the "current directory" in the file system.
All schemas in the
search_path are searched in sequence when using objects. Just like with a search path in the file system.
There is no "root schema", and no nesting. You can't store anything "without schema". Every object is created inside a particular schema. (Except special objects on the database-cluster level, like roles and databases.)
The current role needs privileges to access a schema. Schemas are extremely useful if you want to organize things and still be able to access other "areas" in a simple query.
MySQL does not have anything similar. You would use a separate database for many things solved with a separate schema in PostgreSQL.