28 posts tagged with "postgresql"

Getting to your first dashboard is rarely about the dashboard. It is about provisioning a database, standing up a BI tool, opening a port, copying a connection string, and praying the two halves agree on TLS. By the time anything renders, the afternoon is gone and the chart you actually wanted is still a row in a spreadsheet.

The Launch a BI workspace stack collapses all of that into one launch. You get a complete Metabase workspace wired to your own PostgreSQL, EU-resident, with dashboards in minutes. You do not assemble it. You launch it.

Standing up a headless CMS usually means a weekend. Provision a database. Pick a CMS. Wire it to the database with a connection string you paste into an environment file. Open a firewall rule. Mint an API token. Then, finally, model your first collection. The content platform you actually wanted was always one good afternoon of plumbing away.

The Launch a CMS stack collapses that into one button. You get a production headless CMS running on your own PostgreSQL, EU-resident, in minutes, with nothing to wire by hand.

Building a GraphQL API used to be a project. You stand up a server, wire it to a database, hand-write resolvers for every type, add a subscription transport, build an authorization layer, and keep all of it in sync with your schema as it changes. Weeks of plumbing before a single useful query runs.

The Launch a GraphQL API stack collapses that into one button. Pick it, accept the cost preview, and a few minutes later you have a production GraphQL API over your own PostgreSQL: queries, mutations, real-time subscriptions, and fine-grained permissions. No backend code. EU-resident from the first request.

Spreadsheets are how most teams actually model their work. A table of customers, a tracker of orders, a board of tasks. The tools that make this delightful, the Airtables of the world, give you a grid you can edit by hand and an API you did not have to write. What they do not give you is the database. Your data lives in someone else's product, in a shape you do not control, behind an export button.

Today you can have both. Launch a no-code database stands up NocoDB, the open-source Airtable alternative, wired to your own PostgreSQL. The editing experience is the spreadsheet you wanted. The thing underneath is a real SQL database, in your own account, resident in Europe, that you can query, scale, and back up like any other.

Retrieval-augmented chat is the demo everyone wants and almost nobody ships cleanly. The interface is easy. The plumbing is not. You need a vector store, somewhere to keep the documents, an inference endpoint that does not leak your data, and an app that knows how to reach all three. That is a database, a bucket, an API key, a handful of environment variables, and a firewall rule or two, all wired by hand before you see a single answer.

The rag-chatbot stack collapses that into one launch. Pick it, accept the cost preview, and a few minutes later you are chatting over your own data on infrastructure you own, resident in Europe.

Every platform you have ever shipped on hands you a bag of parts. A database here. A bucket there. An auth provider, a connection string, a set of S3 keys, a firewall rule, an environment variable to remember on Monday. Each part is real and each part works, but none of them know about each other. The wiring is the project. You spend the first afternoon copying credentials between dashboards before your app renders a single useful screen.

Today we ship the opposite of a bag of parts. create-foundry-app is live. One command scaffolds a Next.js app that already declares what it needs. One deploy provisions every one of those resources on FoundryDB, wires them together, and injects the credentials into the running app. No connection strings to copy. No firewall rules to open. No API keys to paste. You write the app and you ship the wired whole, resident in Europe, in one command and one deploy.

And because we know the first question every serious developer asks: it is open-source, it is MIT, and every primitive maps to an open standard, so the same app runs anywhere. You own the convenience, not a lock.

Every managed platform you have ever used hands you a bag of parts. A database here. A bucket there. An API key, a network rule, a connection string, an environment variable. Each one is a primitive, and each one is yours to wire together. The pitch is "look how much you can build." The reality is an afternoon of plumbing before you see a single useful screen, and a config file that only you understand by Friday.

Today we flip that around. FoundryDB Stacks is live. A stack is the finished thing. One button stands up a complete, production-ready application, composed of those same primitives but already wired together, already metered, in minutes, and resident in Europe. You do not assemble the app. You launch it.

Your data already lives in Europe. Your databases run in European zones, your backups stay in European object storage, and your compliance story is clean right up until your application calls a model. Then a prompt full of customer data crosses the Atlantic on a key someone pasted into an environment variable, with no ceiling, no metering, and no answer to the question "where did that text actually go?"

Today we close that gap, and we do something bigger than close it. Three features ship together: vector search as a service over pgvector, embedding pipelines that run as real jobs with schedules and run history, and a managed inference proxy that puts one governed, OpenAI-compatible endpoint in front of OpenAI, Anthropic, Mistral, and Azure OpenAI. Together they make FoundryDB the European AI Data Platform: the one place where your data, your embeddings, and your model calls live under a single set of controls.

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.