Your SaaS.
Their database.

Place selected customers’ data in their own Postgres. Keep the rest in your cloud.

Read the docs
Where customer data livesThe application connects to the LokaDB proxy and cloud Postgres. The agent in the customer environment opens an outbound tunnel to a relay in the cloud and connects to the customer Postgres. Your cloud SaaSapplication PostgreSQLprotocol LokaDBproxy Cloud Postgres(for remaining tenants) Customer environmentAgent CustomerPostgres Agent opens an outboundtunnel to the cloud relay
01 DATA PLACEMENT
THE IDEA
02

One application.
Different places for data.

Use your existing application and PostgreSQL drivers.
Keep most tenants in your cloud, and place selected customers’ data in their own Postgres. Run a compatibility check, choose the tables, and connect the customer’s agent.

EXAMPLE WORKFLOWSHELL
# 1. Check compatibility
$ lokadb check

# 2. Prepare and enable tables
$ lokadb enable -prepare
$ lokadb enable

# 3. Move an organization
$ lokadb move-org

Commands shown schematically. See documentation for required options.

01

Check compatibility

Analyze your schema and recorded workload before moving data.

02

Prepare and enable

Choose the tables and review their relationships and query patterns.

03

Move the data

Connect the agent and move the selected organization to its own Postgres.

△   MVP · Selected PostgreSQL tables only. Review logs, caches and backups separately.

The problem it solves

You are a multi-tenant SaaS

All customers share one Postgres. Then the largest customer says: "our data must live in our own database, in our own network, under our own keys."

The usual answers are bad: a separate deployment of the whole product for one customer, or a rewrite of the data layer of the application.

You want a third way

The customer provides a Postgres. You move that one organization into it. The application neither knows nor cares: the proxy finds the organization in every statement and sends it where the rows are.

One customer at a time, no big-bang migration, and the way back is one command.

How it works

The application talks to the proxy as it talked to Postgres. The cloud never connects into the customer's network: an agent inside it opens one outbound, mutually authenticated tunnel.

Architecture The application connects to the LokaDB proxy. The proxy sends statements for organizations that stay to the cloud database, and statements for a moved organization through a relay and an outbound tunnel opened by an agent in the customer network to the customer's own database. Your cloud Customer network Your appone connection string LokaDB proxyfinds the organization Cloud Postgresorganizations that stay Relayaccepts the tunnel Agentdials out Customer's Postgresthat organization's rows outbound tunnel

1. Check

lokadb check reads your schema, a recording of the workload and the customer database, and says what blocks the move, what is not supported yet and what will behave differently. It changes nothing, and it is free and open source.

2. Enable and move

enable turns the chosen tables into tables partitioned by organization, in place, without copying rows. move-org then moves one organization to its own database while the application keeps writing.

3. Undo any time

move-back returns the organization to the cloud; disable undoes enable. Every step can be stopped and reversed.

What does not change in your application

  • The driver, the ORM and the SQL: tested with unmodified Laravel, Django and Go (GORM over pgx), and with pgx, psycopg, JDBC and PDO clients.
  • Only the connection string changes: host and port point at the proxy.
  • Migrations, prepared statements, transactions, upserts, COPY, cursors, LISTEN/NOTIFY keep working.

What you may need to decide: relations your schema does not declare as foreign keys (common in Rails and Laravel), reports that read across organizations, and background jobs. lokadb check lists every such query and why no organization was found; you declare the missing relations or allow the reviewed reports. A statement that names no organization is refused by default, never sent to every customer database.

What it costs at run time

Measured on eight separate servers, not in Docker on one machine: Postgres 18 with fsync on, two repeats, the median. All figures are for this workload (access by primary key and by an (organization_id, id) index); another workload gives other numbers.

0.2–1 msextra per statement through the proxy, for organizations that stay in the cloud
5–10 %slower for a whole Django application with 16 clients, compared with no proxy
~2×requests/s with a new connection per request (built-in pool): 2,795 against 1,321 direct
2–3 spause of one organization's writes at the switch of a move, for 60–600 MB at 43 ms distance
Throughput and latency with and without LokaDB for organizations that stay in the cloud
With 32 clients the throughput through the proxy is 36–80 % of a direct connection (read 66,500 → 29,800 ops/s, insert 23,700 → 8,600). That is why we suggest a limited pilot on a compatible application, not a blanket guarantee.
Requests per second when every request opens a new connection
PHP-FPM without persistent connections, serverless: the pool is on by default. pgbouncer in our simple setup gave 275 — a measurement of our setup, not a limit of pgbouncer.
Pause of writes at the switch of a move, by organization size
A 600 MB move takes about eight minutes under continuous writes; the organization's writes wait 2–3 s at the end. The first move of an organization adds a longer pause, which has been shortened since this measurement and not re-measured.

A moved organization pays for distance

Its latency is almost linear in the round-trip time to the customer. At 43 ms a read takes 352 ms through the fdw profile and 133 ms through fdw+direct; an update 351 and 89 ms. lokadb check forecasts this before you move anyone.

Scale. One partition per organization. Up to about 100 organizations there is no noticeable price; at 1,000 reads and updates are a third to a half lower; at 3,000 we do not recommend mixed writes yet. Method, scenarios, raw results and the open items: performance.md.

One promise, stated narrowly

The rows of the chosen tables of a moved organization are stored only in that organization's database.

What it gives

  • The proxy only narrows: it takes the organization from the statement itself. A wrong guess gives an empty answer, never another organization's rows.
  • The cloud never reaches into the customer network. One outbound tunnel, mutual TLS, single-use enrolment tokens, certificates that renew themselves and can be revoked, TLS end to end to the customer's database.
  • Passwords and data stay with you and the customer.

What it does not isolate

  • Your application's caches, queues, search indexes, files, logs and error reports.
  • Backups and replicas made before the move.
  • On the fdw profile, the moved rows in transit through the cloud Postgres.
  • It is not an authorization layer: who may read what remains the application's job.

Close direct access to the cloud database so that only the proxy, the relay and administrators connect; lokadb check verifies it. The full list is in limits.md.

Open source core

The proxy, the tunnel (relay and agent), enable, move-org, the way back, migrations, the whole compatibility check and the runner that executes commands inside your network are open source under Apache-2.0. You can run all of it yourself, for free, with no limits on rows, volume or queries.

View on GitHub

Try it first

One command starts a complete small setup and moves an organization out while an application writes:

docker compose -f quickstart/compose.yml up --build

Or use the online demo: a cloud database, organizations in their own databases, a demo application and the compatibility report — nothing to install.

LokaDB Cloud: the control panel and the operations around it

You pay for management, automation and operations — not for rows or queries.

Control panel

Organizations, moves, agents, a connection wizard for the customer's side, a portal for your customer, statistics and monitoring with e-mail alerts.

Check reports in the panel

Every check your runner makes, readable by section: blockers, changes, the latency forecast and the suggested declarations, ready to copy. The check itself is fully open source. Coming next: a report on an uploaded schema without installing anything, an AI advisor over the findings, comparison over time.

Your data stays yours

An open-source runner inside your network contacts the panel by token and executes check, enable, moves and returns there. Passwords and data do not pass through us.

Enterprise can run the panel in its own environment under a signed licence. When a licence expires, only management stops: the proxy and the data keep working.

Pricing

No limits on rows, volume or queries. Billing is by organizations managed in the panel. Payments go through Paddle, our merchant of record, which issues the invoices.

Community

$0
  • The whole open-source core
  • The complete compatibility check
  • Run it yourself, no limits
  • Issues and discussion on GitHub
Get it on GitHub

Starter

$299 / month
  • Control panel
  • 3 organizations
  • Check reports in the panel
  • E-mail support, reply within 2 working days
Request access

Growth

$999 / month
  • Everything in Starter
  • 20 organizations
  • Statistics, monitoring and e-mail alerts
  • E-mail support, reply within 1 working day
Request access

Enterprise

from $2,500 / month
  • Everything in Growth
  • Panel in your environment under a signed licence
  • SLA by agreement
Talk to us

$49 per month for each organization above your plan's limit. Prices are in US dollars; sales tax or VAT is added at checkout where it applies.

Questions

Is it safe to give a service access to our data?

The service never holds your data or your database passwords. The runner that executes commands is open source and runs inside your network; it dials out to the panel with a token and does the work locally. What the panel stores is operational: which organizations exist, the state of moves and agents, the metrics. Read the data processing terms and privacy policy (drafts).

What if your service is unavailable?

The proxy, the tunnel and the data do not depend on the panel. You lose management — starting a move, new statistics — until it is back; applications keep reading and writing. With the open-source core you can run every command yourself at any time.

Does our application need changes?

No code changes for the statements the proxy can place. Where it cannot find the organization, the check tells you which queries and why; you declare a relation or allow the reviewed report. It is a decision, not a rewrite.

What does the customer have to provide?

A Postgres database they run (self-hosted or managed), a host or container for the agent, and an outbound connection from it. No inbound ports are opened. Provisioning the database is the customer's side.

Which applications and Postgres versions?

Tested end to end with Laravel, Django and Go. Postgres 17 and 18. The supported and not-yet-supported lists, honestly, are in the README and the roadmap.

Can we leave?

Yes. move-back returns an organization to the cloud, disable restores plain tables, and the core is open source.

Is it production-proven?

No, and we say so. It is covered by an end-to-end stand and a regression check for every defect found so far, and we suggest a limited pilot with a customer who is willing to be first.

Request access

Tell us a little about your case. We reply by e-mail, usually within a few working days.

We use these details only to answer your request. See the privacy policy. Or write to [email protected].