Blazing Shared Services
Always-on managed services — PostgreSQL, Cache, Storage, Registry, and an Analytical Database — shared across tenants with strict ACL isolation. No dedicated instance per project; one resilient service per tier, multi-tenant by design.
Blazing Shared Services introduces a new deployment primitive: always-on platform services that are shared across tenants, with access control enforced at the ACL layer rather than through physical isolation.
Instead of spinning up a dedicated database or cache per project — wasteful, expensive, and operationally heavy — a single highly-available instance of each service is provisioned per region. Tenants are isolated by ACL: each project gets its own credentials, namespace, and policy boundary, but shares the underlying compute and storage with others on the same infrastructure tier.
The initial service catalog:
**Blazing PG** — A managed PostgreSQL service. Tenants receive their own logical database within a shared cluster. Connection pooling, automated backups, point-in-time recovery, and read replicas are handled at the platform level. Schema and data are strictly ACL-isolated.
**Blazing RPG** — A PostgreSQL proxy and gateway layer that handles connection multiplexing, query routing, and access policy enforcement in front of Blazing PG. Enables fine-grained per-tenant connection limits and audit logging without changes to application code.
**Blazing Cache** — A managed Redis-compatible cache. Tenants operate in isolated keyspaces with per-tenant eviction policies, TTL defaults, and memory quotas. Ideal for session state, ephemeral queues, and hot data tiers.
**Blazing Storage** — S3-compatible object storage with per-tenant bucket isolation and ACL-enforced cross-tenant access policies. Backed by distributed storage across the provider network.
**Blazing Registry** — A shared OCI-compliant container image registry with per-project namespaces, role-based push/pull permissions, and automated vulnerability scanning on push.
**Blazing ADB** — A shared analytical database optimised for OLAP workloads. Tenants submit queries against their own isolated dataset; the underlying columnar engine is shared. Designed for workloads that are too large for OLTP but do not justify a dedicated data warehouse.