The database version shapes how the exercises run
The same query may return a similar result across several engine versions, yet differ in its execution plan, the functions available or the behaviour of the optimiser. That is why the instruction “connect to PostgreSQL” does not define a workstation. You need to state the full server version, the extensions, the settings that matter for the exercises and the client the group will use.
If the material covers administration, the operating system, the location of configuration files and the way the service is managed also matter. In an SQL language course, participants' access can be limited to the database layer. The scope of permissions should match the topic, rather than handing everyone the administrator role by default.
Training data should pose a problem to solve
A few empty tables are enough to demonstrate syntax, but they do not teach analysis. The dataset should contain relationships, missing values, duplicates, varied distributions and edge cases. Performance exercises also need a scale at which an index or a change in the execution plan has an observable effect.
The safest option is synthetic data prepared for the given scenario. You can keep the domain logic, for example orders, payments and refunds, without copying customer names or document numbers from production. The data generator and the seed should be versioned together with the material. Each subsequent run of the training then starts from exactly the same dataset.
Every participant needs their own state
A shared database becomes a problem when the exercises involve INSERT, UPDATE, migrations or index changes. One person may delete a record another needs, and the instructor will not know whether a wrong result comes from the query or from an earlier change to the data.
Isolation can be achieved with a separate instance, database or schema. The choice depends on the goal. A separate schema is lightweight and is enough for many SQL exercises. A separate instance gives more freedom for server configuration, replication or failure scenarios. Account and space names should be unambiguously assigned to participants, and the instructor must have a way to reset a chosen workstation without affecting the others.
Roles show how data security works
Instead of a single account with full privileges, you can prepare roles that fit the scenario: application user, analyst, schema owner and administrator. Participants can then see why an operation is allowed in one context and refused in another. An example like this is more useful than discussing GRANT and REVOKE only on a slide.
Passwords and connection strings should not be hard-coded into the exercises. They can be supplied as environment variables or as a file readable only by the given account. Query logs need to be configured so that they do not record secrets or data that is not needed for analysis.
A result is more than a row count
In an exercise on correctness, the participant should be able to explain why the query returns a given set. Optimisation adds the execution plan, timing, the number of blocks read and the effect of an index. A single timing measurement is not enough, especially when the cache is already warm or other processes are loading the machine.
The instructions can describe the expected properties of the result instead of giving a ready-made query. For example: no duplicate customers, orders without payments included and a stable sort order. Criteria like these let you compare different correct solutions and encourage discussion of trade-offs.
A reset must cover data, roles and configuration
Restoring the tables alone is not enough if a participant has changed permissions, a server parameter or an extension definition. The scope of the reset should match the scope of freedom. In a simple lab, recreating the schema and loading the seed is enough. In an administration scenario, a snapshot of the whole VM or rebuilding the instance is the safer choice.
Run the reset several times before the training and check that it always leads to the same state. Ideally it ends with an automatic check of record counts, the schema version and account availability. The message “the script finished without errors” does not guarantee that the environment is ready.
Ready-made VMs shorten the technical start of the workshop
Separate machines can be prepared with an SQL client, the specified server version, data, materials and tools for inspecting plans. Participants connect through a desktop in the browser or over SSH, depending on the syllabus. The local laptop does not need drivers, a server or several client versions.
Environments created from a single base configuration help you keep a shared starting point. They do not replace the design of the exercises, but they remove the variables that are not the subject of the training. The time can then go on the data model, query quality and the consequences of changes.