MIOSA Data services give your sandboxes and production runtime instances access to persistent storage without any external account setup. When you attach a data service to a project, MIOSA provisions the resource and injects its credentials at boot - your code reads process.env.DATABASE_URL and connects. That is the entire integration.
Phase status
Mental model
Each service fills a different role. Pick the right one for your data shape:
| Service | Use when you need | Persistence |
|---|---|---|
| Postgres | Relational data, joins, transactions, migrations | Durable — survives deploys and sandbox destruction |
| MySQL | MySQL-compatible apps, existing MySQL schemas | Durable — survives deploys and sandbox destruction |
| Redis | Cache, sessions, pub/sub, rate limiting | Durable (AOF/RDB) but treated as cache-class |
| Qdrant | Vector search, semantic similarity, embeddings | Durable — collection data persists across VMs |
| Storage | File uploads, generated assets, binary blobs | Durable — content-addressed object store |
| Auth | Per-project end-user signup, login, and JWT issuance | Durable — user records outlive any VM |
| Volumes | Large or fast filesystem state that does not fit in Postgres | Attached to one runtime instance at a time |
Data persists past your VMs
Sandboxes are ephemeral. Runtime instances are ephemeral. Data is not.
Destroying a sandbox removes the VM - the connected Postgres database is untouched. Publishing a new version does not migrate your schema. Rolling back a deployment does not roll back your database. Data services are managed independently of the compute that connects to them.
This is intentional. It is also why production stays available during deploys: the new version connects to the same database the old version was using.
How credentials are injected
MIOSA injects different credentials based on the environment the runtime instance boots into:
production runtime → DATABASE_URL = postgres://prod-db...
staging runtime → DATABASE_URL = postgres://staging-db...You ship one environment variable name; MIOSA resolves the right value. See Environments.
Quick example
How data services attach
How it fits together
Project
├── Sandbox (ephemeral compute)
│ └── Env vars injected at boot ─────────────────────┐
│ ▼
└── Data Services (durable) MIOSA Data Plane
├── Postgres ←── DATABASE_URL
├── MySQL ←── DATABASE_URL
├── Redis ←── REDIS_URL
├── Qdrant ←── QDRANT_URL
├── Storage ←── STORAGE_BUCKET + STORAGE_ENDPOINT + keys
├── Auth ←── AUTH_URL + AUTH_JWT_SECRET (opt-in)
└── Volumes ←── mount path configured per serviceYour application code is unaware of the infrastructure. It reads standard environment variables, opens connections, and runs. MIOSA operates everything underneath.
Next
Managed Postgres per project. PgBouncer pooling, automated backups, and DATABASE_URL injection.
Managed MySQL per project. DATABASE_URL injection, dedicated instances, data persists across VM destroy.
Managed Redis per project. Cache, session store, and pub/sub. REDIS_URL injected at boot.
Per-project vector database. Semantic search and embedding storage. QDRANT_URL injected at boot.
Object storage buckets per project. Signed-URL uploads and downloads — no credentials in the browser.
Opt-in per-project end-user auth. Signup, login, JWT. AUTH_URL + AUTH_JWT_SECRET injected at boot.
Resend-backed auth email for password reset and email confirmation. Operator-level setup, not per-project.
Persistent block storage attached to a runtime instance. Data survives VM destroy and reattaches.
Enterprise data partner pattern for client-wide structured data, high-volume calculations, reconciliation, and private data-plane deployments.