About the Filess Platform
Filess is a managed database platform engineered for teams that need to prototype quickly and scale responsibly. The platform is organized into two operational models—Shared and Dedicated—so you can align performance, governance, and cost with every stage of your product lifecycle.
Both deployment models expose the same administrative surface: the Filess Console, a REST API, CLI tooling, and Infrastructure-as-Code adapters that will be released alongside additional documentation. The difference lies in the underlying isolation model and the operational guarantees you receive.
Platform at a Glance
| Dimension | Shared Runtime | Dedicated Runtime |
|---|---|---|
| Isolation model | Shared compute, isolated storage namespaces per tenant | Single-tenant compute, network, and storage |
| Ideal for | Dev/test, prototypes, classroom and hackathon workloads | Production, compliance, and latency-sensitive workloads |
| Access level | Managed credentials, no root/superuser | Full root/superuser, custom configs |
| Backups | Managed logical snapshots | Physical backups + PITR |
| Networking | Public endpoints with IP controls (coming), REST orchestration | Private networking, firewall rules, Tailscale, SSH tunnels |
| Engines | MySQL, MariaDB, PostgreSQL, MongoDB | Same catalog + TimescaleDB, PostGIS, pgvector builds |
If you need to spin up a playground in under a minute, start in Shared. If you are signing an SLA or need deterministic performance, head straight to Dedicated.
Shared Runtime
The Shared runtime is designed for non-production environments, experiments, proofs of concept, and lightweight internal tools that still require secure storage. Databases are provisioned inside high-density clusters where compute resources are shared across tenants, while storage remains logically isolated per customer.
Shared Runtime is ideal for rapid prototyping, development environments, and learning projects where speed and cost-effectiveness matter more than guaranteed performance.
Ideal Moments
Rapid Development Create development, QA, and demo databases in seconds without opening infrastructure tickets.
Education & Events Support hackathons, education programs, and independent builders without committing to dedicated capacity.
Prototyping Prototype multi-tenant features before graduating to Dedicated.
Highlights that keep it practical
- Secure tenant isolation: Each database runs under an isolated namespace with encrypted volumes. Data never co-mingles at the storage layer even though CPU and RAM are pooled.
- Burstable performance: Throughput scales with the health of the cluster and is best-effort. Filess automatically migrates noisy neighbors to maintain fairness, but latency-sensitive workloads should graduate to Dedicated.
- Managed backups: Shared databases receive automated logical backups on a rolling schedule. Restore requests can be made through the console or API.
- REST automation: Provision, rotate credentials, and delete databases through the Filess REST API. This enables preview environments, CI jobs, and classroom workflows.
- Guarded surface area: To protect other tenants and keep operations predictable, customer accounts do not receive
rootorsuperuserroles. Certain features—such as MySQL triggers, custom Postgres extensions, or MongoDB server parameters—are intentionally disabled. - Multi-region availability: Select the region closest to your team; Filess gradually expands shared clusters to additional continents as demand grows.
Operational Guardrails
Resource policies CPU and memory quotas are enforced per database to prevent noisy-neighbor incidents.
Audit trails Every administrative action is logged and exportable so you can track who created, rotated, or deleted resources.
Auto-suspension Idle databases can be auto-paused to reclaim shared capacity; they resume on first connection within seconds.
Orchestrate via REST
# Visual example of database creation
# (Imagine a beautiful UI here)
Use the same endpoint to rotate credentials, and attach metadata so preview environments and classroom labs stay tidy without manual clean-up.
Use Shared whenever speed to database matters more than deterministic performance. Migrate to Dedicated once you need granular tuning, private networking, or compliance attestations.
Dedicated Runtime
The Dedicated runtime assigns an isolated compute estate—CPU, RAM, disk, and virtual networking—to every Filess project. You receive full administrative control, deterministic performance, and operational primitives that satisfy production, compliance, and enterprise requirements.
Dedicated Runtime is the recommended target for production workloads, regulated industries, and high-throughput internal systems where deterministic performance and operational transparency are non-negotiable.
Why teams graduate
Single-tenant clusters Every database runs on dedicated VMs or bare-metal nodes with hardware reservations. No other customer shares your CPU cycles, memory lanes, or disk throughput.
Root-level access
Each engine ships with root/superuser credentials, allowing you to enable extensions, tune configuration files, and run maintenance jobs.
Physical backups & PITR Filess performs streaming physical backups and maintains write-ahead logs so you can restore to an exact day, hour, minute, or second before an incident. Point-in-time recovery (PITR) can be invoked self-serve or via support automation.
Percona Monitoring and Management built in Every Dedicated Runtime database includes Percona Monitoring and Management (PMM) out of the box. Get query analytics, performance metrics, database advisors, and alerting with no setup required.
Network controls Apply IP-allow lists through the managed firewall, integrate with Tailscale for private mesh access, and enable SSH tunneling for operators who prefer bastion workflows.
Engine variants Dedicated clusters can run enterprise-ready builds such as TimescaleDB, PostGIS, pgvector-enabled PostgreSQL, or optimized MySQL variants. New flavors are validated and added regularly.
Change windows Schedule rolling restarts, OS patching, and version upgrades during maintenance windows that align with your release calendar.
Additional Capabilities
Encryption everywhere Data is encrypted at rest with customer-dedicated keys, and TLS is enforced in transit. Customer-managed keys (CMK) support is on the roadmap.
High availability Optional multi-zone replicas and automated failover keep RPO/RTO aggressive without manual intervention.
Secret management Inject connection strings into your own vault (HashiCorp Vault, AWS Secrets Manager, etc.) via push or pull workflows.
PITR in practice
1. Incident timestamp 14:02 UTC—a migration script accidentally truncates a table.
2. Select target
In the console, pick 14:01:45 UTC (15 seconds before the incident) or specify the exact 2025-01-12T14:01:45Z via API.
3. Restore flow Filess clones the latest physical backup, replays WAL up to the requested second, and exposes a new endpoint for validation.
4. Traffic swap Promote the restored cluster or replay the fixed data back into live production in minutes instead of hours.
Supported Database Engines
Filess offers the same engine catalog across Shared and Dedicated runtimes, allowing teams to graduate through environments without changing drivers or ORM settings:
- MySQL (8.x)
- MariaDB (10.x)
- PostgreSQL (15.x + enterprise variants such as TimescaleDB and PostGIS)
- MongoDB (6.x)
Engine versions are constantly updated, with long-term support releases and security updates applied automatically. Version pinning and cross-version migrations will be detailed in future documentation drops.
What's Next
Upcoming Documentation
- Provisioning workflows and API examples
- Credential rotation playbooks
- Migration guides for moving from on-prem or other DBaaS providers
- Reference architectures for analytics, commerce, and messaging workloads
Need Help?
Until then, use this page as your single source of truth when deciding which Filess runtime to adopt for each environment. If you need help mapping requirements to the right tier, contact support through the Console or email [email protected].