App Hosting launched with apps served at https://{name}.foundrydb.com from public images. That covers the demo and the internal tool. It does not cover the two things every real deployment needs: your app on your domain, and your app built from a private image. Both shipped alongside the launch, and both are designed so you never hand a plaintext secret around or click through a certificate wizard.

This post covers the two-certificate model behind custom domains and the write-only credential model behind private registries.

Your database lives on FoundryDB. Your app lives somewhere else: a separate PaaS, a VM you babysit, a Kubernetes cluster you would rather not think about. Every query crosses the public internet, hits a firewall rule you opened by IP, and crawls back. Two sets of credentials, two networks, two bills, and a latency floor set by whatever the internet feels like today. That gap is where most of the operational pain in a small-to-medium stack actually lives.

Today we close it. App Hosting on FoundryDB is live. Run your container on a dedicated VM, reachable over HTTPS, wired straight into your managed databases over a private network with credentials handed to it automatically. You deploy your app next to your data, and the connection between them stops being your problem. It becomes the platform's job.

Most managed database products rent you a box. You provision a Postgres, you provision a Kafka, and then the interesting part, the part where data actually flows from one to the other, is handed back to you with a shrug. You stand up Kafka Connect, you hunt for the right Debezium build, you hand-edit pg_hba.conf, you grant REPLICATION, you author a publication, you guess at a slot name, and you pray the two services can even reach each other on the network. That is a runbook, not a product. And until today, it was yours to own.

Not anymore. FoundryDB data pipelines are live. The connection between two services you already own is now a first-class resource you can create, watch, and tear down with a single call. The first pipeline type ships today: change data capture from a PostgreSQL source straight into a Kafka sink. One POST, and the platform does all the plumbing, end to end, idempotently, with nothing exposed to the public internet to make it happen.

For a long time the smart move was to keep the LLM far away from production infrastructure. Not because the model was dumb, but because the blast radius was unbounded. Hand an assistant a shell and a database password and the worst case is not a bad suggestion, it is a confident DROP TABLE. So we built the thing that makes the worst case impossible, and then we handed your assistant the keys.

FoundryDB's MCP server now ships 24 tools, enough to run a service from creation to deletion without ever leaving the chat. Provision a PostgreSQL cluster. Take a backup and check the recovery window. Pull your slowest queries, ask the advisor for an index, and apply it. Scale storage, add a replica, set a maintenance window. The whole operational story, spoken to your assistant in plain language. The reason you can actually trust it with that is a three-layer safety model that sits under every single tool: agents propose, the platform brokers, and the destructive paths refuse to fire on a guess.

Most teams end up with the same API token wired into half a dozen places: the CI pipeline, a monitoring dashboard, a backup script, a Terraform run, and a one-off cron job someone wrote last year. Every one of those tokens can do everything the platform allows, including deleting your production database. That is a lot of blast radius for a token whose only job is to read a metrics endpoint.

Scoped API tokens fix this. A token can now carry a set of scopes that restrict exactly which resource families it can touch and at what level. A monitoring dashboard gets a token that can only read services. A backup script gets a token that can only manage backups. The token that can delete a database stays in a human's password manager, where it belongs.

Every vendor security questionnaire asks the same questions. Where is the data stored? Is it encrypted at rest? Is it encrypted in transit? When was the last backup? How long do you keep audit logs? Answering them usually means a human logging into a console, taking screenshots, copying values into a spreadsheet, and hoping nobody changed anything between the screenshot and the audit.

The compliance report endpoint replaces that ritual with a single API call. It returns a JSON document describing your data posture across every service in your organization, and it attaches an HMAC-SHA256 signature over that document. An auditor can recompute the signature with a verification key and prove the report came from the platform and was not edited on the way to their desk.

Single-zone high availability is wonderful right up until the zone itself is the thing that breaks. A blown rack, a batched datacenter maintenance window, a regional routing incident, and every replica you so carefully provisioned next to your primary goes dark at the exact same moment. Today that stops being your problem to solve by hand. FoundryDB v0.8.0 ships cross-zone clusters: one managed database, spread across three zones, privately peered, with streaming replication that stays on the cloud backbone and never crosses the public internet.

This is the database property you always wanted and never wanted to build yourself. You ask for three zones, and you get a primary in one, replicas in the other two, a private peering mesh wiring them together, and two DNS records that already point at the right nodes. No second cluster to babysit. No VPN to watch. No 3am page because a replication slot filled up while you were asleep.

Babelfish stores everything in a standard PostgreSQL database (babelfish_db). Your T-SQL schemas, tables, stored procedures (compiled to PL/pgSQL internally), triggers, and views are all PostgreSQL objects underneath. This means the backup story for Babelfish is exactly the backup story for PostgreSQL: pgbackrest, WAL archiving, and point-in-time recovery.

This post documents how backups work on a live Babelfish 4.8.0 instance, using confirmed results from FoundryDB staging.

Loading data efficiently is one of the first things you need to sort out when migrating from SQL Server. Babelfish supports several bulk loading patterns natively, but the BULK INSERT statement is not one of them. This post documents what works, what does not, and the best alternatives, all tested live against Babelfish 4.8.0 on PostgreSQL 16.11.

For provisioning instructions, see the Babelfish getting started guide.

Dynamic SQL is one of the most heavily used features in real-world SQL Server applications. Stored procedures that build queries at runtime, parameterised searches, dynamic pivot tables, and flexible reporting queries all rely on it. If you are migrating from SQL Server to Babelfish, you need to know that these patterns work before you commit to the move.

This post documents six dynamic SQL patterns tested against Babelfish 4.8.0 on PostgreSQL 16.11, running as a FoundryDB managed service. Every test passed without modification.