Privacy Policy

In short #

We are a managed PostgreSQL provider. There are two very different kinds of data here, and the distinction runs through this entire document:

The data you put inside your database is yours. We store it, back it up and keep it running. We do not read it, analyse it, sell it, or use it to train anything. For that data we act as a processor on your instructions, and the terms are in our Data Processing Agreement rather than in this policy.

The data about your account — who you are, what you bought, how the service is performing — is data we control, and this policy is about that.

We do not sell personal data. We do not run advertising. We do not use third-party trackers on our website.

---

1. Who we are #

We operate Balta DB from Vilnius, Lithuania, and we are the controller of the personal data described in this policy.

Contact for privacy matters: [email protected]

---

2. Where we are a controller, and where we are a processor #

If your database contains personal data about your own users, you are the controller of it and we process it only to run the service you have bought. We do not access it except as described in section 7.

---

3. What we collect, why, and on what legal basis #

3.1 Account data #

Name, email address, password hash, multi-factor authentication settings, organisation name, role, timezone and language preference.

We do not support passkeys, and this paragraph said we collected passkey credentials. We do not, and never did: the tables that would have held them were dropped without a single row ever being written, because no route ever reached the code that would have written one. A policy that lists a category of credential we do not hold overstates what we have about you.

Purpose: to create and secure your account and control access. Legal basis: performance of a contract (Art. 6(1)(b)).

3.2 Billing data #

Billing name and address, VAT identification number, country, invoice history, subscription state, and a payment-method token supplied by our payment processor.

We never see or store your full card number. It stays with the payment processor.

The payment processor is named on our Subprocessor Register before it starts handling anything, like every other provider.

Purpose: to charge you, issue compliant invoices, and meet tax obligations. Legal basis: contract (Art. 6(1)(b)) and legal obligation (Art. 6(1)(c)) for invoice retention.

3.3 Service operational data #

Names, locations, plans and configuration of your services; resource utilisation and pressure metrics; connection counts; storage growth; backup outcomes; recovery-point exposure; restore verification results; job and provisioning history.

This is telemetry about the service, not about the contents of your database.

Purpose: to run the service, alert you to problems, honour the availability commitments in our SLA, and plan capacity. Legal basis: contract, and our legitimate interest in operating a reliable platform (Art. 6(1)(f)).

3.4 Query Insights #

The Query Insights feature stores normalised query text: parameter values are replaced with placeholders before anything is stored, and utility statements are not collected at all. A query that does not normalise cleanly is discarded rather than stored raw.

You can turn query text collection off entirely in your service's Configuration tab. Aggregate performance metrics continue to work without it.

We handle this as data processed on your behalf, and Balta staff cannot read it without a recorded reason (section 7).

Purpose: to show you which queries cost the most time. Legal basis: contract, as a feature you have enabled.

3.5 Security and access logs #

Authentication events, IP addresses, user agents, session records, API access, and every significant action taken in your account.

Purpose: to detect and investigate unauthorised access, and to give you an audit trail. Legal basis: legitimate interest in the security of the service (Art. 6(1)(f)), and legal obligation where a breach must be investigated.

3.6 Support communications #

Emails, messages sent through the contact form on this site, and any information you choose to include in them.

We run a ticketing system, and it is ours. A ticket you raise from your dashboard is a row in the same database that holds your account and your services, in the same place, under the same access rules. No third party is involved, so nothing here is added to the subprocessor register in section 6, and your ticket does not leave infrastructure we operate in the EU.

A ticket holds what you chose to put in it: a subject, a severity, the service you attached if you attached one, and the messages. Every message records who wrote it and when. Support also reaches us as email, which our mail provider holds, and through the contact form, whose retention is in the table in section 8.

The messages cannot be edited or deleted, by you or by us. The database refuses it. A record of a support conversation that can be tidied afterwards is not a record of what was said, and a conversation is often the only place we told you something. What that means for retention is in section 8, and it is stated there rather than glossed: nothing deletes a support conversation today.

Purpose: to help you. Legal basis: contract, and legitimate interest in improving the service.

Please do not paste production credentials or personal data into a support message. If you do, we will redact it where we can.

3.7 Website usage #

We use self-hosted, cookieless analytics on baltadb.com. No cookie is set, no cross-site identifier is created, no personal profile is built, and the data does not leave infrastructure we operate in the EU. We collect aggregate page views, referrer, approximate country, and device category.

Purpose: to understand which pages are useful. Legal basis: legitimate interest (Art. 6(1)(f)) — see our Cookie Notice for why this does not require consent.

3.8 Marketing email #

There is no way to sign up for one, and we have never sent one. The launch waitlist was the one form that collected an address for marketing, and it was removed on 21 September 2026. Nothing on this site now asks for your address so that we can write to you later.

We still hold the signups made before that date. They are deleted 24 months after the day each one was made (§8), and you can ask us to remove yours sooner by writing to us.

If we ever offer marketing email again, it will be opt-in, this section will say so, and every message will carry a one-click unsubscribe.

Legal basis: consent (Art. 6(1)(a)).

3.9 Email we send you #

Sign-in codes, password resets, alerts about your services and billing notices are sent through Postmark, our transactional email provider. It receives your email address and the content of each message, and keeps the content for up to 45 days. No content from your databases is ever put in an email. Postmark is a United States company and processes this data in the United States; the transfer is covered in section 5.

Purpose: to run your account and tell you about your services. Legal basis: contract (Art. 6(1)(b)).

3.10 Error reports #

When something fails in our website, dashboards or control plane, a report goes to Sentry, our error tracking provider. The reports are stored in Sentry's EU region, in Frankfurt. A report says what failed and where in our code, with the route pattern and a request reference. It never contains content from your databases, it has no field for your name or email address, and values that look like credentials or connection strings are redacted before it leaves our systems. A report sent from your browser reaches Sentry as an ordinary web request, so Sentry sees the IP address it came from. Sentry keeps the account our staff use, our organisation settings, project keys and audit log in the United States, which is why it appears in section 5.

Purpose: to find and fix faults. Legal basis: legitimate interest in operating a reliable service (Art. 6(1)(f)).

---

4. What we do not do #

• We do not sell personal data, and we do not share it with data brokers.
• We do not use your data, or the contents of your databases, to train machine learning models.
• We do not run advertising, or embed third-party advertising or social media trackers.
• We do not use session recording, heatmaps or cross-site tracking.
• We do not read the contents of your database except in the narrow, logged circumstances in section 7.

---

5. Where your data is stored #

Account, billing and operational data is stored in the European Union.

Your database contents are stored in the location you chose when you created the service.

Your backups are stored in two places, and this deserves to be stated plainly: a primary repository in the same region as your service, and a second repository in a different country. This is deliberate — it is what makes your data survive the loss of an entire location — but it means a strict single-country residency claim would be false. The exact countries for each location are published on our Locations page and in our Subprocessor Register, before you buy.

International transfers. Two of the providers on our register process personal data outside the European Economic Area, and each transfer rests on the mechanism named beside it:

• Postmark (AC PM, LLC, Chicago, United States): recipient email address, message content, delivery events, processed in United States. Transfer mechanism: EU-U.S. Data Privacy Framework certification, and Standard Contractual Clauses in its data processing agreement.
• Sentry (Functional Software, Inc., San Francisco, United States): error reports, request references and route patterns, processed in Germany and United States. Transfer mechanism: EU-U.S. Data Privacy Framework certification, with Standard Contractual Clauses in its data processing agreement as the fallback.

---

6. Who we share data with #

We use a small number of subprocessors, each bound by a data processing agreement before it processes anything. The current list, what each one does, and where it processes data, is published at /legal/subprocessors: today that is Hetzner for the servers that run customer databases and the primary backup repository, Scaleway for the second backup repository, Postmark for email and Sentry for error reports.

We commit to publishing changes to that list, with at least 30 days' notice before a new subprocessor starts processing customer data, so that you have time to object.

We may also disclose data where we are legally required to. If we receive a legally binding request for your data, we will notify you unless we are legally prohibited from doing so.

---

7. When Balta staff can access your data #

This matters more than most privacy policies admit, so here is the actual mechanism.

• Staff cannot browse customer data. Access to anything belonging to a customer requires a written reason recorded at the moment of access.
• That reason, and the fact of the access, appears in your own audit log. You can see who looked, when, and why.
• Elevated access expires automatically after a short period and must be requested again.
• Connecting to a running customer database is restricted to the highest privilege level, requires a reason, and notifies you.
• Every staff account is individual, requires multi-factor authentication, and is restricted by network. There are no shared accounts.

We access customer data to investigate a fault you have reported, to respond to an incident affecting the service, or where legally compelled. Not otherwise.

---

8. How long we keep things #

A retention period is a promise that something happens to your data. So this table has a second column saying whether anything actually performs it today. Four answers are possible.

• Enforced — a scheduled job in our platform deletes the data at that point, and a test holds it there.
• Enforced by anonymisation — a scheduled job overwrites the fields that identify you and keeps the record they were attached to, because something we are separately required to keep points at it. A test holds that too, and it is written as a property rather than a list of fields, so a field added later is covered rather than quietly missed.
• Not implemented — the period is what we intend. Nothing performs it yet.
• Outside the platform — the deletion happens in a system that is not the control plane, such as the backup repository, and is governed by that system's configuration.

Legal sign-off register: none. No period below has been reviewed or approved by a lawyer. Every row that states a number is marked awaiting legal sign-off, and stays marked until somebody qualified has settled it. When one is settled its name goes in this register and the marker comes off that row, in the same change. The status column is an engineering fact and is checked by a test; the number beside it is not yet anybody's judgement.

What "enforced by anonymisation" means for your account, exactly.

Ninety days after the last organisation you belong to is closed, a scheduled job overwrites your name, your email address, your password hash, your multi-factor secret, your email verification, your last sign-in time, and your timezone and language settings. Your account row stays, carrying an address that cannot receive mail and no name. Any session still open is deleted at the same moment, in the same database statement, so a credential cannot outlive the identity it belonged to.

The row stays rather than going because your account identifier appears throughout the audit trail, and that identifier is a random string that says nothing about you. Deleting the row would break every record that points at it, including the records that show what was done to your data and by whom. Emptying the fields and keeping the row removes you and keeps the trail.

Three things this does not reach, stated plainly.

• Your organisation's name and VAT number. Invoices we have issued do not carry their own copy of the customer's name — the organisation record is that name. We are required to keep invoices for ten years, so the organisation record is kept for as long as the invoices are, under Art. 17(3)(b). Anonymising it at ninety days would destroy the identity of a record the law requires us to hold.
• Your account if you were removed from an organisation rather than the organisation being closed. The clock above starts when an organisation closes. Being removed from the last organisation you belonged to leaves no such instant to count from, and setting a second period for it is a decision nobody has made rather than a number we should invent here. Ask us under section 9 and we will do it.
• Your address inside the security and audit logs, and inside the record of email we have sent you. Both are covered by their own rows above, and both say Not implemented.

What "not implemented" means here, in each case.

• Invoices and billing records. The law sets a floor and not a ceiling: we are required to keep an invoice for ten years, and nothing requires us to destroy it in the eleventh. Nothing in our platform does either. An invoice cannot be edited or deleted by anybody, us included — the database refuses it — which is what makes the ten years dependable, and is also why there is no point at which invoices go. No deletion period has been set for them.
• Database contents. Deleting a service marks it for permanent deletion after a grace period. The sweep that performs that deletion does not exist, and the length of the grace period is not fixed yet. Your dashboard shows the date that applies to your organisation; that date is the one that counts, and it is not a date this page can state.
• Security and audit logs. The audit trail is append-only by design, which is what makes it an audit trail: nothing in the platform can edit or delete an entry, including us. That also means nothing deletes an entry at twelve months. The trail records IP addresses and user agents, so it contains personal data that currently has no end date.
• Support conversations. Twenty-four months is what we intend, and nothing performs it. The messages on a ticket are append-only: the database refuses to change or remove one, which is what makes a conversation a record of what was said, and it also means nothing can delete the conversation at twenty-four months. This is the audit log's position, arrived at the same way and for the same reason. Making the period real is a decision about whether a support conversation is evidence or correspondence; until somebody makes it, this row says what happens rather than what we would like to happen. Support that reaches us as email is retained by our mail provider under their own configuration, and the contact form's period is the one in the table above.
• Transactional email. The record of a message we sent you keeps the address it was sent to, so that a bounce or a complaint can be matched to it. Nothing deletes those records, and no period has been set for them.

What "outside the platform" means here. Neither backup expiry nor analytics retention is performed by the control plane, so neither is something our own tests can hold. Backups are expired by the backup repository against the window on your service, and it is the window you can see and change. The analytics period is a setting in our analytics instance; while no instance is running there is no analytics data to retain, and the counter starts when one is.

About marketing consent. Joining the waitlist was the consent, and the waitlist row is the record of it. The waitlist was removed on 21 September 2026 and no new row can be created, so what remains is the signups made before that date. Each is deleted 24 months after the day it was made, and asking us to remove yours sooner works today only by writing to us. There is no one-click withdrawal that deletes the record by itself, because there is nothing to unsubscribe from: no marketing message has ever been sent. If that changes, this paragraph changes with it, and every message will carry a working unsubscribe link.

About deletion and backups, stated plainly: when you delete data from your database, it stops being available immediately, but it persists inside existing backups until those backups age out of your retention window. If you chose 30-day retention, deleted data can exist in backups for up to 30 more days. There is no way around this that also preserves point-in-time recovery, and any provider claiming otherwise is describing something other than how backups work. If you need faster erasure guarantees, choose a shorter retention window.

And the same is true of our own database, which is the row above. Your account, your organisation, your invoices and our audit log live in the platform's database, and we back that database up the way we back up yours: continuously, to two repositories in two countries. We keep four full backups in each, taken weekly — between four and five weeks of history. So when a record is deleted or anonymised in the live database, it persists in those backups until the oldest one holding it expires, which is up to five weeks.

We keep four rather than more for exactly this reason: every extra week of history is an extra week an erased account's data exists in a backup. We do not keep fewer because a defect or a bad migration is sometimes noticed late, and a window shorter than that is a window that cannot undo it. The figure comes from the backup configuration itself (deploy/vps/README.md §5), not from a target: if we change the number of backups we keep, this sentence changes in the same edit.

---

9. Your rights #

Under the GDPR you can ask us to: give you a copy of your data (access); correct it (rectification); delete it (erasure); limit what we do with it (restriction); give you a portable copy (portability); or object to processing based on legitimate interests. Where processing is based on consent, you can withdraw that consent at any time.

How to exercise them. Use the request form on our Contact page or email [email protected]. We will respond within one month. If a request is complex we may extend that by two further months, and we will tell you within the first month if we do.

The date we work to. When your request arrives we fix a due date and store it against the request: the earlier of one month and thirty days from receipt. Those two are not the same, and neither is reliably the stricter — one month from 31 January is 28 February, which is sooner than thirty days, while one month from 1 March is thirty-one. Taking whichever falls first means the date is never later than the month this section promises. That fixed date is what our staff see, and it does not move if we later change how the date is worked out.

We may ask you to verify your identity before acting on a request. We will not charge you unless a request is manifestly unfounded or excessive.

How a request is actually carried out. This is worth saying, because "we honour your rights" is easy to write and the mechanism is what decides whether it is true.

• A message you sent us through a form on this site — the contact form, or a data-subject request itself — can be erased by our staff directly. A contact record is deleted outright. A data-subject request is redacted rather than deleted; the reason is at the end of this section.
• A waitlist signup, if you made one before 21 September 2026, is erased by hand. The forms that created them and the screens that read them were removed with the feature, so there is no button for it and a member of staff deletes the row. Every remaining signup is deleted on the clock in §8 whether or not anybody asks.
• An account is erased by hand. There is no automated account-erasure mechanism yet, so a request means a member of staff working through the account's records. That takes longer and it is the honest description of what happens.
• Access and portability are handled by hand for the same reason. There is no self-service export of your account data. Your database contents are a different matter: you can dump them yourself at any time, and that path is built.
• The audit trail is not erased. It records IP addresses, user agents and the actions taken in your account, it is append-only so that it cannot be quietly altered, and that means an erasure does not reach it. We think an audit trail that could be edited on request would be worth less to you than to us, but you should know the trade before you rely on it.

Why a data-subject request is redacted rather than deleted. The record that you asked, when you asked, what the deadline was and how we answered is our own evidence that we complied, and we are required to be able to show it. So the request survives with your address, the text you wrote and the address it was sent from removed, and with the type, the dates and the outcome kept. Nothing in that surviving record identifies you.

Two practical notes. For data inside your own database, you already hold the tools — you can query, modify, export and delete it yourself at any time. And if you are an end user of one of our customers, we are the processor, not the controller: send your request to them, and we will support them in answering it.

Complaints. If you are unhappy with how we have handled your data, we would like the chance to put it right first. You also have the right to complain to the Lithuanian State Data Protection Inspectorate (Valstybinė duomenų apsaugos inspekcija), L. Sapiegos g. 17, 10312 Vilnius, [email protected], or to the supervisory authority in your own country.

---

10. Security #

We publish what we actually do rather than adjectives. In summary: encryption in transit; per-service operating-system isolation; no customer access to the underlying host; backup credentials held by the platform and never inside your database runtime; mandatory multi-factor authentication and network restriction for staff, checked on every authenticated request; and audit logging of every significant action.

Two measures are designed and not yet in force, and this notice names them rather than listing them above. A certificate issued to your service alone is the design for the transit encryption above; nothing issues a per-service certificate today, so the transport is encrypted and the identity it presents is not the one described on our security page. Encryption at rest on host storage is one of the conditions a host must satisfy before it may carry customer services, and no host has been through that check. Neither is a measure you should rely on today, and we will move them into the list above when they are running.

The per-service IP allowlist was the third and is now in force. The rules you set on a database endpoint are applied at the host firewall and in PostgreSQL's own authentication, and an address you have not listed cannot open a connection.

The detail is on our Security and Trust pages.

If there is a breach affecting your personal data, we will notify the supervisory authority within 72 hours where required, and notify you without undue delay where the breach is likely to result in a high risk to you. We will tell you what happened, what we know, and what we are doing — we would rather send an uncomfortable email than a late one.

---

11. Children #

Balta DB is a business service and is not directed at children. You must be at least 18, or the age of majority where you live, to open an account. We do not knowingly collect data from children.

---

12. Automated decision-making #

We do not make decisions producing legal or similarly significant effects about you by automated means. Automated fraud and abuse checks may flag a signup for human review; a person makes the decision.

---

13. Changes to this policy #

We will update this policy as the service changes. Every version is listed at the foot of this page, and the current version is always the one you are reading.

For changes that materially reduce your rights or expand what we do with your data, we will notify account holders by email at least 30 days before the change takes effect.