Privacy policy

Who we are

Client SQL is a hosted service that governs PostgreSQL access for people and coding clients. The service is operated by [legal entity name and registered address] (“we”, “us”). For personal data processed through the service, that entity is the controller; support is available at team@clientsql.com.

What we collect

We collect only what running the service requires.

• Account details. Your name, email address, password hash, and — when two-step verification is enrolled — an encrypted authenticator secret and hashed single-use recovery codes. We never store your password in readable form.
• Workspace details. Workspace name, your role in it, and who invited whom.
• Session and technical data. Session identifiers, browser user-agent, sign-in and activity timestamps, and the network address a request arrived from. Addresses are used to attribute requests and to rate-limit abuse, and are stored as hashed rate-limit keys rather than a browsable history.
• Database connection details. For each database you connect: host, port, database name, environment label, and the login credential. Credentials are encrypted with AES-256-GCM under a per-account key, are never returned to a browser, and are decrypted only for the moment a query or migration needs them.
• Governance records. The SQL statements you run or propose, previews and impact estimates, approval decisions, migration plans and rollback evidence, execution output, and the audit log that links all of it to the person and client that acted. This ledger is append-only, which is the point of the product.
• Email. The address we send account mail to, and the content of the messages we queue.
• Public-site analytics. Aggregate page views on the marketing and legal pages, described below.

Analytics on the public site

We measure visits to the public pages with Umami Cloud. It is cookieless: it sets no cookies, does not fingerprint your device, does not build a profile across sites, and the statistics we see are aggregate counts of page views, referrers, and country. We do not load analytics inside the authenticated workspace, so the databases, schemas, and tables you work with are never sent to an analytics provider.

You can block the analytics script with any content blocker and the site continues to work exactly the same.

What we do not do

• We do not sell your data, and we do not share it for advertising.
• We do not run advertising or cross-site tracking scripts.
• We do not read the contents of your database for our own purposes. Query results exist to answer the request you made and to show you evidence of it.
• We do not use your database data or governance records to train machine-learning models.

How we use it

To create and secure accounts, authenticate sign-ins, enforce the permissions you set, execute the queries and migrations you authorize, send the account mail you expect, keep the audit trail, provide support, prevent abuse, and meet legal obligations. Where data protection law requires a legal basis, we rely on performance of our contract with you, our legitimate interest in keeping the service secure and working, and compliance with legal obligations.

Who processes it with us

We may replace a provider with an equivalent one; this page lists the providers in use.

Where your data is stored

The control-plane database, the audit ledger, and the encrypted credentials live in Google Cloud in asia-south1 (Mumbai, India). If you are elsewhere, your data is transferred to and processed in that region. Transactional email passes through Brevo, and public-site analytics through Umami Cloud.

How it is protected

Traffic is served over HTTPS. Database credentials are encrypted at rest under a per-account key that is itself wrapped by a master key held in a managed secret store. Passwords are hashed with a memory-hard function. Production workspaces require an authenticator for two-step verification, and security-sensitive changes revoke existing browser sessions and coding-client tokens. Every governed action is written to an append-only audit record.

No system is perfect. If we become aware of a breach affecting your personal data, we will notify affected account holders without undue delay.

How long we keep it

• Browser sessions: 12 hours, or 30 minutes idle.
• Verification links: 1 hour. Password-reset links: 30 minutes. Invitations: 72 hours.
• Queued email: the stored body is cleared once the message is accepted for delivery.
• Application logs: 30 days.
• Account, workspace, and governance records: for as long as the workspace exists. Audit records are append-only, so they are not edited or selectively deleted; they are removed when the workspace is deleted.
• Deleted connections: the record is retained in a hidden state so it can be restored, and removed with the workspace.

Your choices and rights

You can update your name and workspace settings from the product. To request a copy, correction, or deletion of your personal data, or to object to processing, write to team@clientsql.com from the address on the account. We will respond within the period the applicable law allows. Deleting an account removes your memberships and personal details; audit records that identify you as an actor are retained until the workspace is deleted, because removing them would break the record that the product exists to keep. If you believe we have handled your data incorrectly you may complain to your local supervisory authority.

Children

Client SQL is a tool for engineering teams. It is not directed at children and is not intended for anyone under 16.

Changes to this policy

When this policy changes we update the date at the top. If a change materially affects how we handle personal data, we will tell account holders by email before it takes effect.