Introduction:
Developers, as a matter of fact, usually work with a local database of their own. There are times, however, when you would want to grant access to the database to a collaborator or test the application with a different notebook computer.
A way to accomplish this seamlessly and securely is through the same Wi-Fi or LAN connection. This means that the information remains private, and the database doesn’t get exposed to the internet, which could pose a security risk, but this is a common method within development teams. This approach is commonly used in professional development setups, including internal engineering environments at Payoda, where secure collaboration is a priority.
Using PostgreSQL as a useful example, I will describe a general method that works with the majority of SQL databases in this blog. In order to maintain the setup’s safety, control, and production-mindedness even in a local development environment, I will also highlight crucial security best practices along the way.
Why Local Network Connections Are Safe
When both laptops are connected through Wi-Fi:
• Communication can only happen among devices on that network
• There is no public IP involved
• Firewall and OS safeguards remain effective
This configuration is typical for:
• Backend API testing
• Sharing test data
• Debugging
• Local development environments
It’s easy, very fast, and totally secure if implemented correctly. From a networking standpoint, private address ranges established by networking standards include local IP addresses like 192.168.x.x. Devices outside of your LAN or Wi-Fi cannot directly access these addresses because they are not routable over the public internet.
An effective first line of defense is provided by this innate isolation. A person cannot connect unless they are physically or logically connected to the same network, even if they are aware of the database credentials. This configuration closely resembles security procedures used in corporate internal networks when paired with firewall rules and database-level authentication.
It’s critical to comprehend the roles in this setup before moving on to the configuration steps. PostgreSQL is installed and operational on a single machine that serves as the database host. Tools like DBeaver, pgAdmin, or application code are used to access the database from the other machine, which serves as the client.
Only the host computer—not the client laptop—is subject to all configuration modifications, including firewall rules and PostgreSQL settings. When troubleshooting, this distinction helps prevent confusion.
Step 1 - Find the Host Machine's IP Address
“The host machine is where the database resides. Its LAN IP address is required.”
Windows: IPConfig
Look for IPv4 address (for example, 192.168.1.100).
This IP address is how your computer will connect. One important thing to keep in mind is that LAN IP addresses are often assigned dynamically. This means the IP address of the host machine may change after a reboot or router restart.
If connections suddenly stop working after everything was previously configured correctly, checking whether the IP address has changed should be one of the first troubleshooting steps
Step 2 - Configure PostgreSQL to Listen on the LAN IP
This step is slightly more involved and explains how PostgreSQL, by default, will listen only on “localhost.” To connect to PostgreSQL on another laptop, a user needs to:
1. Open postgresql.conf on server laptop
2. listen_addresses = ‘localhost’
3. Change to your LAN IP: listen_addresses = ‘192.68.1.100’
Do not use ‘*’ if the laptop is connected to a public network. Otherwise, PostgreSQL will be exposed through all the interfaces.
The network interfaces that PostgreSQL will bind to are specified by the listen_addresses parameter. The database will only accept connections via that interface if it is set to a particular LAN IP.
It is generally discouraged to use ‘*’ unless the server is properly firewalled and operating in a controlled environment, even though it enables PostgreSQL to listen on all interfaces. Particularly on developer laptops, explicit IP binding is thought to be a more secure and reliable setup.
Step 3 - Allow Client Laptop in pg_hba.conf
Make sure that PostgreSQL manages connectivity by IP address through pg_hba.conf. Add your laptop’s IP:
host all all 192.168.1.34/32 scram-sha-256
192.168.1.34 should be replaced with the IP.
The pg_hba.conf file is essentially the gatekeeper for your PostgreSQL database. Connections will be refused even if your database listens to your network interface.
By setting the subnet mask to /32, it is ensured that only one exact IP address is allowed. It prevents other computers on the same Wi-Fi network from accessing the database even if they use valid access details.
Step 4 - Restarting the PostgreSQL Service
Windows:
Restarting PostgreSQL service using Services.msc. Even after modifications have been done on configuration files such as postgresql.conf and pg_hba.conf, PostgreSQL will not implement these modifications automatically. The PostgreSQL service will need restarting to implement the new modifications. This has often been missed and is one of the most common errors why a configuration works but fails.
When using Windows, PostgreSQL usually operates as an application running in the background as a service. Restarting PostgreSQL means opening Services.msc, finding the PostgreSQL service based on your PostgreSQL version installed in your system, and completing a restart operation. Restarting this service ensures that PostgreSQL reloads its configuration files and starts listening based on new settings after completing the restart operation successfully and PostgreSQL becoming operational again.
If a restart is missed, PostgreSQL continues to run with the previous setup, causing potential connection time-outs or denial-of-access problems. A restart is thus necessary to ensure that all recent changes have been properly and effectually implemented before continuing with the next steps.
Step 5 - Enable Firewall for Safety at this point
Within the internal network too, restrict access to PostgreSQL only through trusted IP addresses.
Windows:
- Inbound Rules → New Rule → Port → TCP 5432 → Allow
- Scope → Remote IP → Enter your client IP (192.168.1.34) → Finish Now only your laptop is able to connect, even within the same Wi-Fi network.
Firewalls constitute the second line of defense. Although it is possible to control authentication on PostgreSQL, it is the firewall that gets to decide who is allowed to knock on the doorstep.
This is especially common in enterprise networks and assists in minimizing errors, particularly if the laptops tend to roam between multiple networks.
Step 6 - Connecting from Laptop
You are now ready to:
Open up DBeaver (or your preferred SQL client):
- New Connection → PostgreSQL
- Fill
| Field | Example |
|---|---|
Host | 192.168.1.40 |
Port | 5432 |
Database | my_app_db |
Username | postgres (or your user) |
Password | your password |
As a client, you simply need network connectivity. The database name is simply the name that tells PostgreSQL which database you want to attach to. The permissions determine the privileges you will need once you are connected.
“Failure to gain access at this point is usually more a question of permissions than networking.”
Step 7 - Troubleshooting
| Error | Cause | Solution |
|---|---|---|
Connection timed out | Server listening only on localhost / firewall blocked | Check listen_addresses, pg_hba.conf, firewall rules |
Authentication failed | Wrong user/password or IP not allowed | Verify pg_hba.conf entry & credentials |
Cannot connect to specific DB | DB doesn’t exist or access restricted | Verify DB name & permissions |
Even with careful setup, connection problems can still happen. A missed restart, a small typo, or a cached configuration is often enough to cause issues.
A structured troubleshooting approach saves time and avoids unnecessary configuration changes.
Step 8 - Checklist of Consolidated Security
1. PostgreSQL listens on LAN IP (not ‘*’)
2. pg_hba.conf only permits your IP
3. Firewall will allow only your laptop to connect to port 5432
4. Strong Password for PostgreSQL
5. PostgreSQL restart after configuration changes
These steps may look simple, but together they form a solid security baseline. This is very similar to how internal databases are handled in professional environments- restricted access, clear rules, and minimal exposure.
Conclusion
To connect an SQL database on the same Wi-Fi is easy, secure, and professional if done right. At Payoda, secure-by-design engineering is central to how teams collaborate and scale. If you’re looking to implement enterprise-grade database access, networking, and security practices across development and production environments, Payoda helps organizations design reliable, compliant data architectures that grow with their applications while maintaining performance, traceability, and controlled access across teams.
Below are all the best practices to follow during this process
• Filter links to certain IPs only
• Open ports strictly as needed
• Use strong, secure passwords
• Restart PostgreSQL after configuration completion
Even though this tutorial will focus on PostgreSQL, the concepts explained here are almost universally applicable to all SQL databases, including SQL Server, Oracle, or even MySQL.
Just like this, you can connect your computer to your local network, and other machines can connect into that local network, allowing you to communicate directly.
FAQ'S
- Can I connect to my PostgreSQL database from another laptop without being on the same Wi-Fi network?
No. For this setup, both machines must be connected to the same Wi-Fi or LAN network. The database is exposed only on a private IP address, which cannot be accessed over the public internet. This restriction is intentional and helps keep the database secure. If remote access is required from outside the network, a VPN or properly secured cloud deployment should be considered instead.
- Is it safe to open PostgreSQL port 5432 on my laptop?
Yes, it is safe when done correctly. The port should be opened only for specific trusted IP addresses and not for all inbound traffic. Combined with firewall rules, strong passwords, and restricted pg_hba.conf entries, opening port 5432 on a local network is a common and accepted practice in development environments.
- Why does the connection fail even though the IP address and port are correct?
This usually happens when PostgreSQL has not been restarted after configuration changes, or when the pg_hba.conf file does not explicitly allow the client IP address. It can also occur if the database name or user permissions are incorrect. Verifying the service restart, access rules, and user privileges typically resolves this issue quickly.
Talk to our solutions expert today.
Our digital world changes every day, every minute, and every second - stay updated.
