Your data stays in your own database

Reference data looks harmless until you read it. A cost center list is a map of how the company is organised. A customer segment mapping says who you sell to. A budget registry is the budget. Security reviews ask the same two questions about all of it: where does it live, and who else holds a copy?

On the Enterprise plan the answer can be your own database. gridmap keeps your values, registry rows, their history and the audit trail in a PostgreSQL schema you own, and holds no copy of them itself. This post covers what that means in practice: what moves, what stays with gridmap, how the move works, and what to plan for before you turn it on.

What lives in your database

Once your organisation has a data target, everything that is your data is read from and written to it:

• the values in every gridmap, source and mapped
• registry rows, and the change history of each row
• the activity log: who changed which value or row, and when
• comments on values and rows
• the values in your value sets
• files uploaded to the import wizard

The app works the same way on top. The lookup API, scheduled syncs, row-level security, exports and the activity log all work on the data in your database, and the people using gridmap will not notice where it is stored.

What gridmap keeps

gridmap still needs to know how your organisation is set up. It keeps that configuration in its own database in Azure Sweden Central:

• users, groups, SSO settings and API keys
• projects, and the structure of your gridmaps and registries: names, columns and settings
• access grants, including the values in row-level security rules
• value set definitions, with their sources and schedules
• connections to your source databases, with the credentials encrypted
• the settings for your target, with its password encrypted
• job logs, usage counters and notifications

Two items on that list can contain business values, and a security reviewer will want to know about them. A row-level security rule names the values a user may see, such as the location "Stockholm". A gridmap's AI instructions can include examples. Both are configuration, and both stay with gridmap.

AI mapping is the other case to know about. When a gridmap uses AI, the source values being mapped are sent to the AI provider, whichever database stores them. If a gridmap's values must never leave your database, turn AI off for that gridmap.

What you need

A PostgreSQL database that gridmap can reach. Self-hosted PostgreSQL, Azure Database for PostgreSQL, Amazon RDS or Aurora PostgreSQL, and Google Cloud SQL for PostgreSQL all work.

gridmap connects from one fixed address, 135.225.228.10, and uses TLS by default. Allow that address on the database port and nothing wider.

Give gridmap a login that can work in one schema and nothing else. The Targets page has a setup script that creates the schema and a login with exactly those rights. When you add the target, gridmap checks the login. It must be able to create, write and delete in its schema, which gridmap proves inside a transaction that it rolls back. It then warns about anything broader: superuser, the right to create roles or databases, write access through built-in roles, or read access to tables outside the schema. A login with more rights still works, but the warning tells your DBA exactly what to take away.

How the move works

An admin adds the target under Targets, runs the check, and chooses Move Data Here. The move runs in the background:

1. Edits pause across your organisation, and everyone can keep reading. gridmap waits about 35 seconds so that anything already being saved has finished.
2. It copies your data into your schema, table by table.
3. It counts the rows on both sides and compares them with what it copied. Any difference stops the move, and your data stays where it was.
4. It switches your organisation over. From here on, reads and writes go to your database, and editing works again.
5. It deletes its own copy.

How long the pause lasts depends on how much data you have.

If a move fails, gridmap puts your organisation back the way it was before the move started, so people can keep working, and removes the partial copy.

Moving back works the same way in the other direction. Move Data Back copies your data into gridmap, checks it, switches, and empties gridmap's tables in your schema. The schema and its tables stay, in case you move again later.

Things to plan for

Distance. gridmap runs in Azure Sweden Central. With a target, every page and every API call makes a round trip to your database, so a database in the same part of the world keeps the app quick.

Backups and retention. These are yours now. gridmap backs up its own database, which no longer holds your data, so your database's backup and retention policy is the one that protects your mappings.

Availability. If your database is down, gridmap cannot read or write your data until it is back. Signing in and settings keep working, and pages that show data give an error until it is back.

Schema changes. When a gridmap release adds a column to one of the data tables, gridmap adds it to your schema as well. It only ever adds tables and columns, which is why its login needs to be able to create them in its own schema.

Frequently asked questions

Does gridmap keep a backup or a cache of our data? No. After the move gridmap deletes its copy. From then on it reads your data from your database each time it needs it.

Can we look at what gridmap stores in our schema? Yes. It is an ordinary PostgreSQL schema with ordinary tables. Query them, back them up and monitor them like anything else in your database.

Can we move back? Yes, at any time, from the same page.

Which databases can be a target? PostgreSQL, in any of the forms listed above. Your source connections can still be any of the databases gridmap reads from.

Which plan includes it? Enterprise. Write to info@stormyran.se and we will turn it on for your organisation.