The Enclave Has No Managed Database — Now What?

Your application uses RDS for its database, ElastiCache for its session cache, and S3 for file storage. These are reasonable architecture choices. They are also the reason your application will not deploy to most DoW enclaves without engineering work that isn't visible from reading your deployment guide.

The enclave has no managed PostgreSQL. No managed MSSQL. No S3. No ElastiCache. Your entire data layer assumes services that don't exist in the target environment.

This is the third most common failure class I find when deploying commercial applications against a hardened DoW baseline — after policy admission and image provenance. And it is the one that produces the widest estimates, because the solution is often "build a containerized replacement," and most teams have never done that inside a hardened Kubernetes environment.

Why the services are missing

Commercial cloud environments offer managed services because the cloud provider operates them. AWS gives you RDS, and you don't think about database availability, backups, or patching — it's handled.

DoW-hardened enclaves — Platform One, Game Warden, program-office Big Bang environments — are built on Kubernetes with strict policy enforcement. They provide the compute substrate. They don't provide managed databases, managed caches, or managed object storage as a service to tenant applications. Some enclaves offer limited shared services, but the availability and configuration varies by platform and impact level.

If your application needs a database, you bring a database — as a container running inside the same hardened environment, subject to the same image requirements, the same policy enforcement, and the same storage constraints as every other workload.

What it takes to containerize a database in a Kubernetes enclave

The concept is straightforward: run your database as a container instead of a managed service. The implementation requires specific engineering:

A hardened database image. The official PostgreSQL or MSSQL Docker image carries hundreds of CVEs in its Debian base and runs as root. It will not pass admission. You need a hardened base image with the database compiled or installed on top of it, running as a non-root user, with a read-only root filesystem and explicit writable volume mounts.

Custom extensions, compiled. If your application depends on PostgreSQL extensions — pg_trgm, btree_gist, unaccent, ICU collation — those extensions must be compiled into the hardened image. You can't install them at runtime because the root filesystem is read-only and the container has no network access to package repositories.

Persistent storage. The database needs durable storage that survives pod restarts. This means a PersistentVolumeClaim (PVC) backed by whatever storage class the enclave offers. The storage class, access mode, and size constraints vary by platform.

Initialization and migration. An init container handles schema creation on first deployment and schema migration on upgrades. This is the pattern most teams are least familiar with — running database migrations in a Kubernetes init container rather than through a managed service console or a manual SSH session.

Backup strategy. In commercial cloud, RDS handles automated backups. In the enclave, you need a CronJob that takes periodic backups to a persistent volume. The backup strategy must be documented in the authorization artifacts — the contingency and disaster recovery plans reference it directly.

mTLS compatibility. All inter-service communication traverses Istio's service mesh with mutual TLS. Database connections that use their own TLS may double-encrypt or fail certificate validation. The connection configuration needs to account for the mesh.

A concrete example: an MSSQL container with no managed service

I deployed a commercial ASP.NET application with an MSSQL backend to IL-4 and TOP SECRET environments in fall 2025. The target enclave offered no managed SQL service — not a limited one, not a shared one. None.

The solution was a purpose-made MSSQL container that handled database initialization, schema migration, and steady-state operation. The application's data layer was preserved without a product rewrite. The vendor's engineers didn't have to learn containerized database operations — Millabs built the container, and the vendor's application connected to it the same way it connected to managed MSSQL in commercial cloud.

The database container took approximately one week of engineering. The application is now operational on JWICS.

A separate modeled analysis — deploying an open-source project management platform against the same baseline — identified the same pattern with PostgreSQL. The application depends on PostgreSQL 16+ with custom extensions (pg_trgm, btree_gist, unaccent, ICU collation). No managed PostgreSQL exists in the target enclave. The replacement: a containerized PostgreSQL with extensions compiled into a hardened image, PVC-backed storage, an init container for migration, and a CronJob for backups. Estimated effort: 3–5 days.

The pattern repeats

Every commercial application I've deployed or analyzed against a hardened baseline hits some version of this:

These rates use the GSA Alliant 3 / OASIS+ midpoint ($175/hr) for cleared DevSecOps engineers. On the commercial market, the same profile bills $200–$325/hr — a cleared engineer with enclave deployment experience in the National Capital Region commands a premium because the supply is small and the clearance pipeline is 9–18 months long.

The effort is bounded and predictable — once you've identified which services are missing. The problem is that most teams don't identify the gaps until they're on the platform, discovering them one at a time against the review pipeline's cadence.

Why estimates blow up here

Missing managed services produce the widest cost estimates because the gap between "we need to replace RDS" and "we have a running containerized PostgreSQL in a hardened enclave" looks enormous if you haven't done it before. Teams estimate weeks or months because they're pricing the unknown.

After you've done it once, the pattern is clear: hardened image, PVC, init container, backup CronJob, mesh-aware connection config. The level of effort is days, not months. But you can't know that until you've seen the specific failures, which is what the lab exists to show you.

A fit screen costs $24,500 and identifies every missing managed service in the first week — along with the specific replacement approach and effort estimate for each one. That's cheaper than one sprint spent discovering a single missing service on the live platform.

But the real cost isn't the replacement engineering — it's what happens when you don't know the service is missing. Each discovery on a live platform is a submission-rejection-fix cycle at the platform's review cadence. A 5-person team waiting on a 2-week review cycle burns roughly $70,000 in idle cost at GSA rates ($175/hr). At commercial cleared rates ($200–$325/hr), that same delay costs $80,000–$130,000. Multiply by 3–4 missing services discovered sequentially, and the cost of not having a lab exceeds the cost of every Millabs service combined.

Robert Burckner is the founder of Millabs Corporation, a Service-Disabled Veteran-Owned Small Business. He built a purpose-made MSSQL container to deploy a commercial application to IL-4 and TOP SECRET via Game Warden when the target enclave offered no managed database.

If your data layer assumes managed services and you need to deploy to a DoW enclave, contact Millabs.