← Back to Home

Database Connection Documentation

Everything you need to know about securely connecting your databases

Overview

WhoPrompt securely connects to your database to run read-only queries. Your credentials are encrypted using AES-256-GCM encryption and stored securely. We never access your data directly - all queries run through secure, isolated connections.

Security First

All database credentials are encrypted at rest. We use industry-standard encryption and never log or store your query results permanently. Only read-only SELECT queries are allowed.

Supported Databases

PostgreSQL

Full support for PostgreSQL 9.6+. Recommended for production use.

  • ✓ Native connection support
  • ✓ SSL/TLS encryption
  • ✓ Connection pooling

MySQL

Compatible with MySQL 5.7+ and MariaDB 10.2+.

  • ✓ Native connection support
  • ✓ SSL/TLS encryption
  • ✓ Connection pooling

SQL Server

Microsoft SQL Server 2016+ and Azure SQL Database.

  • ✓ Native connection support
  • ✓ Encrypted connections
  • ✓ Windows & SQL authentication

SQLite

File-based database support for development and small datasets.

  • ✓ Local file support
  • ✓ Fast queries
  • ✓ No server required

Security Best Practices

Use Read-Only Database Users

Create a dedicated database user with only SELECT permissions. This ensures WhoPrompt can only read data, never modify it.

PostgreSQL:

CREATE USER dbstuff_readonly WITH PASSWORD 'secure_password';
GRANT CONNECT ON DATABASE mydb TO dbstuff_readonly;
GRANT USAGE ON SCHEMA public TO dbstuff_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO dbstuff_readonly;

MySQL:

CREATE USER 'dbstuff_readonly'@'%' IDENTIFIED BY 'secure_password';
GRANT SELECT ON mydb.* TO 'dbstuff_readonly'@'%';
FLUSH PRIVILEGES;

SQL Server:

CREATE LOGIN dbstuff_readonly WITH PASSWORD = 'Secure_Password123!';
CREATE USER dbstuff_readonly FOR LOGIN dbstuff_readonly;
GRANT SELECT ON SCHEMA::dbo TO dbstuff_readonly;

SQLite:

SQLite uses file-system permissions. Ensure the file has read-only access for the application user.

Enable SSL/TLS Connections

Always use SSL/TLS to encrypt data in transit. Most cloud database providers (Neon, Supabase, AWS RDS) enable SSL by default.

Whitelist IP Addresses (Optional)

For additional security, configure your database firewall to only accept connections from WhoPrompt's IP addresses.

Rotate Credentials Regularly

Change your database passwords periodically and update them in WhoPrompt. We recommend rotating every 90 days.

Connection String Formats

PostgreSQL

postgresql://username:password@hostname:5432/database_name?sslmode=require

Examples:

  • • Neon: postgresql://user:pass@ep-xxx.aws.neon.tech/dbname?sslmode=require
  • • Supabase: postgresql://postgres:pass@db.xxx.supabase.co:5432/postgres

MySQL

mysql://username:password@hostname:3306/database_name

Add ?ssl=true for SSL connections.

SQL Server

Server=hostname,1433;Database=dbname;User Id=username;Password=password;Encrypt=true;

SQLite

sqlite:///absolute/path/to/database.db

SSL/TLS Configuration

SSL/TLS encrypts data transmitted between WhoPrompt and your database, protecting credentials and query results from interception.

When to Use SSL

Production databases accessible over the internet
Cloud-hosted databases (AWS RDS, Azure, GCP, etc.)
Databases containing sensitive information
Local development databases (localhost)

SSL Modes (PostgreSQL)

ModeDescriptionRecommended
disableNo SSL encryptionNo
requireSSL required, no certificate verificationYes
verify-fullSSL with full certificate verificationBest

Do's and Don'ts

Do's

  • ✓Create a dedicated read-only user for WhoPrompt
  • ✓Use SSL/TLS for all production connections
  • ✓Test connections before saving them
  • ✓Use strong, unique passwords for database users
  • ✓Monitor database logs for unusual activity
  • ✓Keep your database software up to date
  • ✓Document your connection configurations

Don'ts

  • ✗Never use admin or superuser accounts
  • ✗Don't grant INSERT, UPDATE, or DELETE permissions
  • ✗Avoid hardcoding credentials in application code
  • ✗Don't share database credentials across multiple services
  • ✗Never disable SSL for production databases
  • ✗Don't use default or weak passwords
  • ✗Avoid exposing databases directly to the internet without firewall rules

Troubleshooting Common Issues

Connection Timeout

Symptoms: "Connection timeout" or "Could not connect to database"

Solutions:

  • Verify your database server is running and accessible
  • Check firewall rules allow incoming connections
  • Confirm the hostname and port are correct
  • Ensure your database accepts remote connections

Authentication Failed

Symptoms: "Invalid username or password" or "Access denied"

Solutions:

  • Double-check username and password are correct
  • Verify the user has proper permissions (at minimum SELECT)
  • Check if the user is allowed to connect from remote hosts
  • For PostgreSQL: Check pg_hba.conf for host-based authentication rules

SSL/TLS Errors

Symptoms: "SSL connection error" or "Certificate verification failed"

Solutions:

  • Enable SSL in your connection settings
  • Try using sslmode=require instead of verify-full
  • Ensure your database server has SSL properly configured
  • Check that SSL certificates are valid and not expired

Permission Denied on Queries

Symptoms: "Permission denied for table" or "Access denied"

Solutions:

  • Grant SELECT permission on all required tables
  • For PostgreSQL: Grant USAGE on schemas
  • Verify the user can access the specified database
  • Check table-level and column-level permissions

Need Help?

Can't find what you're looking for? Our support team is here to help.

Contact SupportEmail Us