Developer docs · Enterprise
Connect your database
Blipbind Enterprise can store your operational data in a PostgreSQL database you own — your infrastructure, your region, your retention rules. You apply in-product, we review the request, and then you connect the database yourself. No onboarding call required.
Approval is the only step that waits on us, and it’s there so we can confirm the region and the arrangement before your records live somewhere new. Everything else is in your hands, on your schedule.
Overview
Choose My own database when you sign up — or open Data & residency on an existing workspace and apply from there. Tell us about your organisation, wait for approval, then provision a Postgres database and connect it. We verify it, apply our schema, and from then on that page shows the live health of the connection.
Which of two shapes this takes depends on where you start:
- • New workspace. If you chose your own database at signup, reports, jobs and assets stay closed until it’s connected. That’s deliberate: none of your operational data is ever written to our cloud, so there is no migration to trust later. Team invitations and access control work throughout, and you can switch to Blipbind cloud at any point and start immediately.
- • Existing workspace. Nothing is locked and nothing stops. You keep working on Blipbind’s cloud for the whole process; at the end we move your existing records across in a scheduled window (step 8).
1. Apply
We ask for your registered legal entity, the jurisdiction it sits in, where the database will be hosted, roughly how many people will use it, and what’s driving the requirement. The last question matters most — a specific answer (“our class society requires survey records to remain in Singapore”) gets approved faster than a general one.
2. Review
A Blipbind engineer reviews the request. We aim to respond within two business days and email your technical contact either way. If we can’t approve it as it stands you’ll get the specific reason, and you can correct the details and resubmit yourself — there’s no support queue in between.
3. Prerequisites
- • PostgreSQL 16 or newer, with the
pgvectorextension installable. - • TLS enabled — we refuse plaintext connections.
- • Reachable from Blipbind’s AWS region. If you filter by IP, allowlist our egress addresses; they’re shown on the connect step and in your approval email.
- • A dedicated database for Blipbind, not shared with other applications.
- • Backups and disaster recovery are yours to run. We never take a copy.
4. Create a scoped role
Create a database and a role Blipbind will use. The role owns its schema so we can apply and maintain the managed schema for you, but it does not need superuser.
-- Run as an admin on your Postgres instance
CREATE DATABASE blipbind;
CREATE ROLE blipbind_app WITH LOGIN PASSWORD 'use-a-strong-generated-secret';
GRANT ALL PRIVILEGES ON DATABASE blipbind TO blipbind_app;
-- Inside the blipbind database:
\connect blipbind
GRANT ALL ON SCHEMA public TO blipbind_app;
ALTER DATABASE blipbind OWNER TO blipbind_app;
-- pgvector is required for report search
CREATE EXTENSION IF NOT EXISTS vector;5. Connect it
Enter the host, port, database, role and password on the connect step. Here is exactly what happens to that password:
- • It is assembled into a connection string in memory.
- • That string is written straight to an AWS Secrets Manager secret dedicated to your company.
- • Blipbind stores only the reference to that secret. The password is never written to our database, never logged, and never returned by any API.
- • The connection string is resolved from the secret at connection time and cached in memory for minutes at a time.
Because we keep no readable copy, there is no “edit credentials” screen — rotating the password means submitting the form again, which writes a new version of the same secret. Prefer to hold the credential in your own AWS account instead? Ask us about registering a secret ARN you own; it’s supported, just not self-serve.
6. Verification
We immediately run six checks against your database and show you the results. A failure is expected on the first try — each one names what to fix, and you can rerun the checks without re-entering your credentials.
| Check | What it verifies |
|---|---|
| Network reachable | We can open a connection to the host and port you gave us. |
| PostgreSQL version | PostgreSQL 16 or newer. |
| pgvector | The vector extension is available (used for report search). |
| Encrypted connection | The connection negotiates TLS; plaintext is refused. |
| Schema privileges | The role can create and alter tables in its schema. |
| Managed schema | Our changelogs apply cleanly and the schema is current. |
7. Managed schema
Once the checks pass, Blipbind applies its schema to your database and records the result. You never run migrations yourself — every Blipbind release ships its schema changes to your database as part of our deploy pipeline. If a migration ever fails, that tenant is paused (requests return a retryable error) rather than run against a mismatched schema, and we’re alerted.
This usually completes within a few minutes. Your workspace unlocks by itself the moment it lands.
8. Move your existing data
Only applies if you already have records in Blipbind’s cloud. A brand-new workspace has nothing to move and goes live as soon as the schema lands.
Your database is registered and verified but deliberately not yet serving — switching first would leave your existing reports behind. Your team keeps working normally, and everything they create in the meantime is included in the move. When you’re ready, request a migration window from the Data & residency page. We copy your reports, assets and job history across, verify the row counts match, and only then switch you over. Usually inside a business day, with no downtime for your team.
9. Monitor it
The Data & residency page shows live connection status, round-trip latency, schema state, and an activity log of every lifecycle transition, verification run and health change — the same record you can hand to an auditor. If the connection degrades, you see it there first.
What stays with us
Worth being precise about, because “bring your own database” does not mean everything moves:
| Data | Lives in |
|---|---|
| Reports, assets, jobs, media metadata, chat, embeddings | Your database |
| User profiles, teams, access control | Your database (after full cutover) |
| Email addresses, password hashes, OAuth links | Blipbind — always |
| Photos, audio and document files | Blipbind's S3 — always |
Credentials stay on our control plane on purpose: sign-in and password reset must keep working even when your database is unreachable. Media files are a known gap — bring-your-own bucket is not available yet. See the security overview for the full split.