POWER STUDIO

PostgreSQL Database Server

Power Studio stores station data in a PostgreSQL database. This includes tracks, metadata, playlists, formats, users and many application settings.

Install PostgreSQL

  1. Download the Windows installer from the official PostgreSQL Windows download page: https://www.postgresql.org/download/windows/
  2. Run the installer as an administrator.
  3. Leave the installation folder and data folder at their defaults unless the station deliberately uses another location.
  4. Set a strong password for the postgres database user and store it securely.
  5. Leave the default port at 5432 unless the station has a specific reason to use another port.
  6. Select the correct locale for the station, for example Dutch, Netherlands or Dutch, Belgium.
  7. Do not select pgAdmin in the PostgreSQL installer. Install pgAdmin separately after the PostgreSQL server installation.
  8. Disable Stack Builder at the end of the installer. It is not required for Power Studio.

The PostgreSQL password is not a Power Studio user password. It is used by the application and the Configuration Tool to connect to the database.

Store the password with the station's technical documentation. It is needed for database configuration, backups, restores and workstation replacement.

Install pgAdmin Separately

pgAdmin is needed for practical database administration, backup restore workflows and inspection, but it should be installed separately from the PostgreSQL server installer.

For Power Studio installations, install PostgreSQL first and then install pgAdmin separately from the official pgAdmin download page: https://www.pgadmin.org/download/

Installing pgAdmin separately makes future maintenance easier:

  • PostgreSQL server upgrades can be planned without also changing pgAdmin.
  • pgAdmin can be updated independently when a new pgAdmin version is released.
  • Removing or reinstalling pgAdmin does not disturb the PostgreSQL server installation.
  • pgAdmin can be installed only on the database server or administrator workstation instead of every Power Studio client.

Secure Network Access

If Power Studio and PostgreSQL run on the same computer, keep PostgreSQL local-only where possible. The default PostgreSQL setting listens only on localhost, which is the safest choice for a stand-alone installation.

If other Power Studio clients need to connect to the database, allow only the station network or the specific Power Studio workstations. Avoid exposing PostgreSQL to the public internet. If a direct public port is unavoidable, treat it as a documented exception and add extra safeguards.

PostgreSQL network security has three layers:

  1. postgresql.conf decides which server network interfaces accept connection attempts.
  2. pg_hba.conf decides which client addresses, databases and users are allowed to authenticate.
  3. The Windows Firewall decides which remote computers can reach the PostgreSQL port at all.

Use all three. pg_hba.conf is important, but it should not be the only protection.

Configure Listening Addresses

Open postgresql.conf in a plain text editor such as Notepad. The file is usually in:

C:\Program Files\PostgreSQL\[version]\data\postgresql.conf

For a stand-alone computer, keep PostgreSQL local-only:

listen_addresses = 'localhost'

For a database server on the station LAN, listen only on localhost and the server's LAN IP address:

listen_addresses = 'localhost,192.168.10.10'

Replace 192.168.10.10 with the fixed IP address of the database server. Avoid listen_addresses = '*' unless there is a documented reason and the firewall and pg_hba.conf are locked down.

Changing listen_addresses requires a PostgreSQL service restart.

Restrict pg_hba.conf To The Station's Network

Open pg_hba.conf. The file is usually in:

C:\Program Files\PostgreSQL\[version]\data\pg_hba.conf

Do not use these broad examples in production:

host    all             all             0.0.0.0/0               md5
host    all             all             ::/0                    md5

They allow connection attempts from every IPv4 or IPv6 address if the port is reachable.

Use the exact Power Studio database name, the database user used by Power Studio, and the station subnet. Example for a station LAN 192.168.10.0/24:

# Local connections from the database server itself
host    powerstudio     powerstudio_app  127.0.0.1/32           scram-sha-256
host    powerstudio     powerstudio_app  ::1/128                scram-sha-256

# Power Studio workstations on the station LAN
host    powerstudio     powerstudio_app  192.168.10.0/24        scram-sha-256

Replace:

  • powerstudio with the actual database name from the station license.
  • powerstudio_app with the PostgreSQL login used by the application.
  • 192.168.10.0/24 with the station network.

If you do not know the CIDR notation for the station network, use an online subnet calculator such as Subnet Calculator CIDR. Enter the IP address and subnet mask used by a Power Studio workstation to determine the network address and prefix length. For example, a workstation address in 192.168.10.x with subnet mask 255.255.255.0 usually belongs to 192.168.10.0/24.

If the current installation still uses the built-in postgres user for Power Studio connections, do not change the user name blindly. First verify the database configuration and update workflow. Even then, restrict the rule to the exact database and station network:

host    powerstudio     postgres         192.168.10.0/24        scram-sha-256

For tighter security, allow only the known workstation IP addresses:

host    powerstudio     powerstudio_app  192.168.10.21/32       scram-sha-256
host    powerstudio     powerstudio_app  192.168.10.22/32       scram-sha-256

If the station uses multiple trusted subnets, add one explicit line per subnet. Avoid samenet for production unless the server has only the intended network interfaces; a server with VPN, Wi-Fi or additional adapters can make samenet broader than expected.

Save the file. On Windows, new connections use changed pg_hba.conf rules immediately, but using Reload Configuration from the PostgreSQL Start Menu folder is still a good operational habit. Existing connections are not forced to reconnect.

Restrict The Windows Firewall

On the database server, create an inbound rule for TCP port 5432 that is limited to the station network.

Example PowerShell command for a station LAN:

New-NetFirewallRule `
  -DisplayName "PostgreSQL 5432 - Power Studio LAN" `
  -Direction Inbound `
  -Action Allow `
  -Protocol TCP `
  -LocalPort 5432 `
  -RemoteAddress 192.168.10.0/24 `
  -Profile Domain,Private

For specific workstations:

New-NetFirewallRule `
  -DisplayName "PostgreSQL 5432 - Power Studio Workstations" `
  -Direction Inbound `
  -Action Allow `
  -Protocol TCP `
  -LocalPort 5432 `
  -RemoteAddress 192.168.10.21,192.168.10.22 `
  -Profile Domain,Private

Then check Windows Firewall with Advanced Security and remove or disable any broader PostgreSQL inbound rule that allows Any remote address. The database should not be reachable from the Public network profile.

Use Strong Authentication

For new installations, prefer SCRAM-SHA-256 password authentication:

password_encryption = scram-sha-256

Use scram-sha-256 in pg_hba.conf for Power Studio database connections. If an existing installation uses md5, first confirm that all Power Studio clients and PostgreSQL client libraries support SCRAM before changing it. After changing password_encryption, reset the database user passwords so they are stored with the new method.

Avoid trust authentication for Power Studio databases. With trust, any client that can reach the PostgreSQL server can log in as the matching database user without a password.

Use A Dedicated Database Role Where Possible

Use the postgres superuser for database administration, backups, restores and controlled upgrades. For normal application connections, a dedicated PostgreSQL login is safer when supported by the installation.

The application role should only have access to the Power Studio database it actually uses. Do not reuse one PostgreSQL login across unrelated stations, test databases or customer environments.

Database Updates With An Alternative User

The Power Studio Configuration Tool has a Use alternative database connection option. This is useful when the normal Power Studio connection uses a restricted database user, but database updates need a user with schema or DDL permissions.

A practical security pattern is:

  • Configure normal Power Studio clients with the least privileged user that is suitable for daily operation.
  • Keep a separate update/admin user for Configuration Tool database updates.
  • Use Use alternative database connection only when running Update.
  • Do not save the update/admin credentials as the normal workstation connection.
  • Store the update/admin password securely and use it only during controlled updates.

This makes it possible to reduce the privileges used during daily playout while still allowing the Configuration Tool to create or update tables, indexes and other database objects when needed.

Remote Access: Prefer A VPN

If users need to connect to the Power Studio database from outside the local studio network, prefer a VPN over a direct public PostgreSQL port.

Use a VPN first, then treat the VPN address range as another trusted network that still needs explicit PostgreSQL and firewall rules.

One practical option is Tailscale:

  • Install Tailscale directly on the database server.
  • Install Tailscale directly on the file server if audio is stored on a separate machine.
  • Install Tailscale on the remote workstation.
  • Use Tailscale access controls so only approved users and devices can reach the database server.
  • Allow PostgreSQL and Windows Firewall access only from the required Tailscale device IP addresses.
  • Keep the normal LAN restrictions in place for local studio clients.

This direct-client setup is usually the simplest Tailscale design for Power Studio. The database server and file server are part of the Tailscale network themselves, so they can be protected as individual machines instead of exposing a larger part of the studio network.

For example, if a remote Power Studio workstation has the Tailscale IP 100.101.102.103, add a specific pg_hba.conf line for that remote workstation:

host    powerstudio     powerstudio_app  100.101.102.103/32     scram-sha-256

And scope the Windows Firewall rule to the same remote address:

New-NetFirewallRule `
  -DisplayName "PostgreSQL 5432 - Power Studio VPN" `
  -Direction Inbound `
  -Action Allow `
  -Protocol TCP `
  -LocalPort 5432 `
  -RemoteAddress 100.101.102.103 `
  -Profile Domain,Private

If the station needs to give an external presenter, DJ or support engineer access, consider Tailscale machine sharing for only the required machine. The external user does not need a user account in the station's tailnet, but they do need to accept the share with their own Tailscale identity. Share only the database server, file server or workstation that is required, and revoke the share when the work is finished.

If A Direct Internet Port Is Unavoidable

A direct internet-facing PostgreSQL port is not the preferred setup. If the station deliberately chooses it anyway, use stronger controls than for a normal LAN-only setup:

  • Use a dedicated PostgreSQL login for Power Studio, not the postgres superuser.
  • Restrict pg_hba.conf to the exact database and user.
  • Restrict the Windows Firewall rule to known static public source IP addresses whenever possible.
  • Use scram-sha-256, not md5, password or trust.
  • Use a long random password. A practical minimum is two randomly generated GUID-style values concatenated, or a password-manager generated password with comparable length and randomness.
  • Rotate the password when a remote computer or remote user is no longer trusted.
  • Monitor PostgreSQL and firewall logs for failed login attempts.
  • Keep PostgreSQL and Windows patched.

Example PowerShell command to generate a long random password-like value:

([guid]::NewGuid().ToString("N") + [guid]::NewGuid().ToString("N"))

This produces a 64-character hexadecimal value. Store it in the station password manager, not in a shared document.

Security Checklist

Before putting the database server into production, verify:

  • PostgreSQL does not listen on public or unused network interfaces.
  • pg_hba.conf contains no 0.0.0.0/0, ::/0 or all address rule for the Power Studio database.
  • Rules are limited to the exact database, user and station subnet or workstation addresses.
  • Windows Firewall allows port 5432 only from the station network or known workstations.
  • Remote users connect through a VPN where possible.
  • Any direct public PostgreSQL port is a documented exception with restricted source IP addresses and a long random password.
  • The postgres password and application database password are strong and stored securely.
  • Regular users do not use the PostgreSQL superuser account for daily work.
  • The Configuration Tool update/admin user is separate from the normal Power Studio user when the installation supports this.
  • Backups are protected with the same care as the live database.
  • PostgreSQL and Windows are patched through the station's maintenance process.

Official references:

Create The Database

  1. Open pgAdmin.
  2. Connect to the local PostgreSQL server using the database password.
  3. Create a new empty database.
  4. Use the database name supplied with the Power Studio license.

The Power Studio license is tied to the specific station database and database name. Use the exact spelling from the license information.

Do not reuse a database name from another station or test environment. A wrong database name can make a workstation appear correctly configured while it is connected to the wrong library, formats and users.