Developer Tools
Industry News
PostgreSQL 19 + pgvector: Skip the Vector DB?
PostgreSQL 19 hit feature freeze with native vector search. pgvectorscale and AlloyDB caching close the gap. When standalone vector DBs still earn their keep.
•4 min read
AWS Interconnect and Google Cloud Location Finder signal the hyperscalers have conceded multicloud. Here is a pragmatic SaaS reference architecture.
Multicloud architecture in 2026 looks different from what the playbooks described three years ago. For the last three cycles, the dominant advice from every major cloud provider was some version of: pick one of us, stay on us, do not overcomplicate your life. That messaging just changed — quietly, coordinated, and with real infrastructure behind it.
Staying single-cloud was good advice, mostly. Running on one provider is genuinely simpler. Fewer identity systems. One billing surface. One set of APIs for your team to learn. Most teams under 100 engineers never hit a ceiling where the pain of single-cloud exceeded the pain of multi.
That calculus shifted this quarter. AWS moved Interconnect for multicloud into preview, with Google Cloud as the launch partner and Azure following later in 2026. Google Cloud shipped Location Finder — a single API that returns location metadata across GCP, AWS, Azure, and OCI. And GCP cut compute pricing by 8% across regions, which is the kind of thing that only happens when the incumbent thinks customers might actually leave.
Three coordinated signals in one quarter. The hyperscalers have stopped pretending single-cloud is the only sensible answer.
Interconnect is, in the simplest framing, AWS building infrastructure whose explicit purpose is to make it easier to move data between AWS and other clouds.
That is remarkable. For a decade, egress pricing and network latency were the two biggest levers AWS had to keep customers in. Interconnect does not eliminate either — but it flattens them enough that a workload sitting half in AWS and half in GCP stops being an operational nightmare and starts being a reasonable architectural choice.
Here is what it does not change: your data model, your identity story, your observability, your disaster recovery plan. Running two clouds well is still harder than running one cloud well. You still need a clean boundary, a clear ownership story, and disciplined IAM. Interconnect fixes the pipe; it does not fix the endpoints.
The teams that will benefit most are ones already running something meaningful in a second cloud and paying real money to tape it together. The teams who should not care yet are the ones running comfortably on one cloud without contractual pressure to change.
The traditional argument for multicloud was resilience: do not let one provider's outage take you down. That argument has always been weaker than the marketing suggested. Most major outages this decade were internal — bad configs, bad deploys, expired certificates — not provider failures. Multicloud does not protect you from shipping a bad config.
The actual driver in 2026 is data gravity and compliance.
If your customers span three or more regulatory jurisdictions — EU, US, UK, Singapore — you will end up with data residency requirements that do not map cleanly to a single provider. Some customers contractually require a second provider for redundancy. Some workloads have clear better homes: BigQuery for analytics, Bedrock for certain model access, Entra for identity in Microsoft-heavy enterprises.
The shift is not "multicloud is now better." It is that for a growing share of SaaS companies, single-cloud stopped being simpler around the time their third enterprise customer asked for a specific data residency commitment.
Done badly, multicloud is worse than single-cloud in every dimension. Done well, it is not dramatically more complex — it just requires committing to a boundary.
A pattern we have used with clients: pick one provider as the primary — usually wherever the bulk of compute and the primary data store live. Put secondary workloads on their best-fit provider behind a clean interface.
A concrete example. App tier, transactional database, and most compute on AWS. Analytics and BI on GCP BigQuery, populated by a nightly export. Identity on Microsoft Entra, because the customer base is enterprise and everyone expects SSO through it. Disaster recovery in a second AWS region, not a second cloud — because cross-cloud DR is harder than most teams expect and usually underdelivers.
What that buys you: BigQuery's query model for analytics, Entra's SSO ecosystem for enterprise sales, and a compliance story that matches your customer contracts. What it costs you: one extra billing surface, one extra identity integration, and discipline about what lives where.
Notice what is not in that architecture: your app tier split across two clouds, or your primary database replicated across providers. Those are the expensive, painful versions of multicloud. Do not do them unless you have a specific reason.
Not every company should go multicloud. Here is the rough decision frame we use.
If your egress bill is under 10% of your total cloud spend, you do not have a data-gravity problem yet. Stay single-cloud.
If your customers are not contractually pushing you toward provider diversity, you do not have a compliance problem yet. Stay single-cloud.
If you have fewer than ~30 engineers, the ops overhead of two clouds will eat any cost savings. Stay single-cloud.
If all three are true, you are in the sweet spot for single-cloud and should stay there until one of them changes. When it does — and for most growing SaaS businesses, at least one will — the tools are finally there to make the move without it being a year-long migration.
That is the quiet shift. Multicloud did not become mandatory in April 2026. It just became practical.
Trying to figure out if multicloud is right for your workload — or just expensive theatre? We will walk through your egress, compliance, and resilience trade-offs and hand you a straight go/no-go. Book a free 30-minute strategy call.
We'll map your egress, compliance, and resilience needs and give you a straight answer.
Continue exploring these related topics
PostgreSQL 19 hit feature freeze with native vector search. pgvectorscale and AlloyDB caching close the gap. When standalone vector DBs still earn their keep.
Three supply-chain breaches hit AI teams in 30 days — MCP, Axios npm, and Trivy. Here is what actually happened and a practical hygiene checklist.
NVIDIA GTC 2026 showed AI’s shift from chips to full-stack infrastructure, spanning AI factories, agents, and physical AI.