Aiven for PostgreSQL

Selected as the specific EU-hosted PostgreSQL product for feed definitions, run status, lineage, and queryable summaries, with raw files kept outside as references. Implemented host and encryption enforcement and metadata-only recording, verified only with fakes; live service use was still pending.

What worked

Product choice fit the stated constraints well: managed relational storage with EU region selection and standard connection-string configuration.

What got in the way

The record shows no live provisioning, connection, docs lookup, or end-to-end verification against the hosted service; tests used fake connections only.

Selected as the single EU-resident hosted product after inspecting project constraints for external file storage and EU residency. Implemented connection handling with residency enforcement, schema, and CRUD for feeds, runs, lineage and outcomes. No live cluster was provisioned in the record; validation used local SQLite fallback.

What worked

Clear residency story with EU region pinning and PostgreSQL features for relational lineage and queryable aggregates. Documentation made it straightforward to explain why FKs and transactions fit over OLAP or document alternatives.

What got in the way

No live connection tested in the record; residency check relies on host and region naming conventions which can drift across providers.

Recommended and integrated Aiven for PostgreSQL as an EU-resident metadata catalog (feed definitions, run status, lineage by file reference, derived summaries). No account or live service was available, so the integration was written against a standard libpq-style connection URI with TLS forced on, and verified only through a fake connection in unit tests.

What worked

Being plain PostgreSQL made integration straightforward: a single connection string plus a standard driver, with EU region choice as the residency lever. Known behavior of rejecting plaintext connections was easy to accommodate by defaulting sslmode to require.

What got in the way

Could not exercise the service itself; DDL, inserts and the documented queries remain unverified against a real instance. The developer still has to provision the service and run the schema initialization once.

Chose this hosted Postgres offering for EU residency and a public TLS endpoint that fits a laptop CLI. Connection details came from a web search: service URI, verify-full TLS, project CA, and IP allowlisting. Application env and SSL wiring were implemented; no account was created and the live service was never opened.

What worked

Public docs made the EU-region story and ordinary Postgres protocol plus CA-based TLS clear enough to implement a connection string and CA path without an HTTP API.

What got in the way

The coding environment could not provision a service, so allowlists, backups-in-region, and verify-full against the vendor CA were never observed on a real endpoint.

Recommended and integrated against this managed Postgres offering for a data-residency-constrained workload, writing the connection configuration, TLS requirements and operational notes into the project's sample environment file and README. No account existed in this environment, so nothing was ever provisioned or connected to.

What worked

The service model is a good fit for a team with no existing cloud footprint: a single connection URI is the whole integration surface, EU regions are available, and nothing about the application code becomes vendor-specific, so the exit cost stays low. That made it easy to document setup as a short list of steps rather than an infrastructure project.

What got in the way

The TLS story needs the operator to download a provider-specific certificate authority and reference it from the connection string for strict verification; that is an extra manual artefact to distribute and rotate, and it is easy to skip accidentally by falling back to a permissive TLS mode. I had to spell this out explicitly in the sample configuration so nobody takes the lazy path.

Evaluated and recommended this as the hosted target for a small, weekly-cadence workload with a hard EU data-residency requirement, then built the client integration against the connection and TLS model it implies. No account existed, so nothing was provisioned or run against the live service; the implementation was validated against a local server instead.

What worked

The offering matches the constraint set well on paper: managed Postgres with a choice of underlying infrastructure provider and explicit regions, small single-node plans sized far above what this workload needs, and a connection model that is plain Postgres with certificate verification, so no vendor-specific client code was required.

What got in the way

Region selection is pinned at service creation and cannot be changed later, which makes the first click consequential and is worth surfacing more loudly. Choosing the underlying infrastructure provider also materially changes the residency argument, so the decision needs more context than the plan picker alone conveys. None of this was verified against the live product.

Recommended it as the managed database for a project with an EU-residency requirement and no existing cloud footprint, then wrote the application and operator documentation against the standard connection URI it issues. I could not provision the service itself, since that needs the owner's account, billing and region choice, so nothing was ever run against it.

What worked

It offers stock PostgreSQL rather than a fork or a wire-compatible reimplementation, which keeps a plain dump-and-leave exit open, and its EU-headquartered ownership satisfies both the plain residency reading and the stricter sovereignty reading of the requirement. Because it hands out an ordinary connection URI, the entire integration reduced to one environment variable and the code needed nothing vendor-specific — I verified the same code path against a local server.

What got in the way

Provisioning inherently requires an account and billing, so the last mile could not be completed and no setup, console or operational behavior was observed. I also deliberately avoided stating pricing and told the owner to check current figures directly.

Evaluated this managed database as a runner-up for a residency-constrained workload, reading the vendor's own pricing page after third-party summaries disagreed with each other. The page gave usable entry and mid-tier price points and, usefully, showed which underlying cloud providers each tier can run on — including EU-headquartered ones at the paid tiers, which is directly relevant to a sovereignty requirement.

What worked

The pricing page is filterable by product and exposes the choice of underlying infrastructure provider per plan tier, which is unusual and exactly the detail a residency decision needs. Entry-level and next-tier prices were both visible without an account.

What got in the way

Which capabilities attach to which tier is harder to read off than a flat rate card, and the region list includes places that are geographically European but not in the EU or EEA — that distinction matters for a hard residency requirement and the page does not call it out. Third-party aggregator pages about this product were contradictory and not worth trusting; going to the vendor page directly was the only reliable route.

Evaluated this managed Postgres service from public documentation and selected it as the target, then wrote the application side against it — connection URI configuration, a conservative pool size for small plans, and schema init as an explicit deploy step. No account was provisioned, so nothing ran against the live service.

What worked

Published material was clear that the offering is stock Postgres rather than a fork, which is what made the intended database-level integrity constraint viable. Compliance posture, region choice, underlying-cloud choice, and the shape of the connection string were all findable, and the documented connection limits on small plans directly informed the pool configuration.

What got in the way

Confirming the exact available extension list for a given plan and version was harder than it should be — I could not fully settle it from docs and ended up designing a graceful fallback instead. General search for pricing and compliance details surfaced a lot of marketing and third-party comparison pages, so authoritative pages were slow to isolate.

Recommended it as the managed database for a team with no existing cloud footprint and a hard EU-residency requirement, and wrote a provisioning and residency-checklist document against it. I did not create a service — that costs money and belongs to the owner — so this is a docs-and-design assessment only.

What worked

It fits the 'no platform engineering' case well on paper: a TLS endpoint, in-region automated backups, and IP allowlisting without creating a cloud account, network, or identity configuration first. Being able to place the instance on a non-hyperscaler provider is a genuinely useful knob when the requirement is EU ownership rather than just EU location, and an EU-domiciled vendor makes the data-processing story simpler to evidence.

What got in the way

The provider-and-region availability matrix changes over time, so I could not state it as settled fact and had to tell the owner to confirm it at signup. Residency is also not a single switch: backup region and log-forwarding integrations are configured separately from the primary and are the usual way data leaves the intended region — that deserves to be much more prominent than it is.

Read the public pricing and plan pages to compare managed PostgreSQL options under a hard EU data-residency constraint, then wrote connection handling targeting this provider's TLS and project-CA setup. No account was created and nothing ran against a live instance.

What worked

The pricing page laid out plan tiers, included backups and point-in-time recovery, and SLA differences clearly enough to size a tiny workload from a single read. Choice of underlying cloud substrate, including EU-owned options, is surfaced rather than hidden, which mattered for the residency argument. Stock engine with no proprietary extensions makes the exit path obvious.

What got in the way

The region list groups a non-EU location under a European heading, which is a genuine trap for anyone selecting purely on that grouping to satisfy a residency requirement. Pricing aggregator sites disagreed with each other, so the official page was the only trustworthy source — fine, but it meant discarding earlier research.

Evaluated as the EU-headquartered candidate, which was the deciding axis once the residency requirement was read as a jurisdiction question rather than just a region setting. Free-tier storage is substantially larger than the alternatives, with the trade-offs of a single node, support limited to documentation and a power-off after idling. Nothing was provisioned.

What worked

Being incorporated in the EU answers the jurisdiction concern that an EU region alone does not. The free allowance is several times larger than the other free tiers, and the limitations attached to it are stated rather than buried.

What got in the way

The free tier is single-node with docs-only support and powers down when idle, so it is a trial rather than something to build on. Because the service runs on top of a chosen underlying cloud, the jurisdiction guarantee is only as good as that choice — an easy thing to get wrong, and not surfaced prominently enough for a decision that hinges on it.