Skip to main content
Galactic Core enforces multi-tenancy at two levels: inside a deployment by row-level security, and across tenants by physical isolation. Neither depends on application code remembering to filter — both guarantees live in the infrastructure, below the application.

​
Every row belongs to a store

The unit of tenancy is the store. Every business table carries a store_id, and every query is constrained to one store — not by a WHERE store_id = ? an engineer has to remember, but by row-level security enforced in the database itself.
When a request authenticates, the platform verifies the caller is authorized for the store it names and sets that store as the active scope, and the database’s row-level security policies filter every read and write to it. A query cannot reach another store’s data, and a bug in application code cannot cross the boundary either, because the boundary is enforced a layer below the application.
Authorizing the caller for the store and setting the scope is folded into the same single auth call that validates the key — no extra round trip. The scope is re-established per request, so it is bound to the authenticated caller and never inferred from a previous one. See Request Lifecycle.

​
Postgres is the system of record

A relational Postgres database is the single source of truth for the catalog, orders, customers, inventory, and accounting. Everything else — the caches, the search index, the recommendation models — is derived from it and can be rebuilt from it. The cache accelerates reads; it is never authoritative. Read-heavy access goes through purpose-built read views rather than raw tables. A single query returns a product with its variants, media, stock, and category joins already assembled, so a catalog read is one indexed lookup instead of a fan-out of joins assembled at request time.

​
Per-deployment isolation

Row-level security separates stores within a deployment; physical isolation separates deployments from one another. Each deployment — a single merchant on the shared platform, a marketplace operator, or an enterprise client — runs on its own dedicated stack: a separate database and its own API layer.

No co-mingling

A marketplace operator’s data lives in its own database, never in a pool shared with other operators. Isolation is a product guarantee, not a query filter.

Contained blast radius

One deployment’s load spike, migration, or incident cannot affect another’s — there is no shared database or shared compute to contend for.

Independent scaling

A high-volume operator’s stack scales independently of everyone else’s, and can be placed and tuned for its own footprint.

Clean compliance boundary

Data-residency and compliance obligations map cleanly onto a per-tenant stack rather than a shared database that must be reasoned about row by row.
Taken together, these properties cover the confidentiality and integrity sides of the CIA triad: row-level security and per-deployment isolation keep each tenant’s data confidential, and the server-side pricing authority and ACID writes described in the Request Lifecycle keep it intact. Availability — the third side — is the subject of Scaling & Reliability.

​
Production and sandbox share a stack, not data

A sandbox environment runs alongside production within each deployment, so developers can build against realistic data without touching real orders. Environment-scoped tables carry an environment marker; production is the default, and only test-keyed API calls write sandbox rows. Sandbox data is purged on a schedule and never appears in any admin or storefront surface. See Sandbox.

Scaling & Reliability

Read replicas, rate limits, and how the platform holds up under load.

Core Concepts

Keys, environments, and the conventions that hold across every endpoint.