The New AI Stack in 2026

In 2023, the stack was simple: pick a Large Language Model (LLM), wrap it in a chat User Interface (UI), ship. In 2026, production artificial intelligence (AI) looks like a five-layer cake:

Model → Agent → MCP → Tools → Infrastructure

The model reasons. The agent plans, remembers, and enforces policy. Model Context Protocol (MCP) standardizes how the agent reaches the outside world. Tools are the actual systems of record: GitHub, Jira, Customer Relationship Management (CRM), databases, browsers. Infrastructure is where it all runs: gateways, identity, sandboxes, Kubernetes (K8s), observability, and horizontally scaled MCP servers (Model Context Protocol, n.d.; TrueFoundry, 2026; Microsoft, 2026).

Teams that treat "we use GPT" as the whole architecture build demos. Teams that map all five layers build systems that survive contact with enterprise reality.

Key Abbreviations in This Post

• LLM (Large Language Model): A neural network trained on text for language understanding and generation.
• SLM (Small Language Model): A compact model optimized for on-device or low-cost inference.
• MCP (Model Context Protocol): Open standard connecting AI hosts to tools, resources, and prompts (Model Context Protocol, n.d.).
• API (Application Programming Interface): Programmatic access to software systems.
• JSON-RPC (JSON Remote Procedure Call): Protocol MCP uses for host-server communication.
• A2A (Agent-to-Agent): Google's protocol for agent discovery and delegation (Google, n.d.).
• CRM (Customer Relationship Management): Software for customer records and sales workflows.
• IAM (Identity and Access Management): Systems governing who or what can access resources.
• NHI (Non-Human Identity): Credentials used by service accounts, agents, and automation.
• K8s (Kubernetes): Container orchestration platform for scaling services.
• SEP (Specification Enhancement Proposal): Formal MCP spec change document.

The One-Minute Version

• Model: The reasoning engine. Increasingly swappable and partially commoditized.
• Agent: The product layer. Harness, memory, orchestration, discovery, governance.
• MCP: The standard wire format between agents and capabilities. Stateless as of July 2026 (Model Context Protocol, 2026).
• Tools: Real integrations that mutate state in your organization.
• Infrastructure: Identity, scaling, audit, sandboxes, and policy enforcement outside the model.
• Moat in 2026: Layers 2 through 5, not layer 1 (TrueFoundry, 2026; Knowlee, 2026).

Old Stack vs New Stack

Era	Stack	What broke
2023 chatbot	Model + UI	Human copy-paste integration, no memory, no audit
2024 copilot	Model + plugins/RAG	Custom glue per integration, tool sprawl in prompt
2026 agent platform	Model + Agent + MCP + Tools + Infra	Complex, but composable and governable

Layer 1: Model (The Engine, Not the Product)

The model is where most conversations start and where least durable advantage lives in 2026. GPT-6 Astra, Claude Opus-class, Gemini, Phi-4-reasoning, local Small Language Models (SLMs) on laptop Neural Processing Units (NPUs): all are interchangeable inputs to the same agent harness (OpenAI, 2026; Microsoft Research, 2025; Chandra & Krishnamoorthi, 2026).

What the model provides:

• Language understanding and generation.
• Reasoning over context (quality varies by tier).
• Tool-call intent: which function to invoke with what arguments.

What the model does not provide:

• Persistent memory across sessions (unless the agent layer adds it).
• Reliable multi-step workflow execution.
• Authentication, authorization, or audit trails.
• Guaranteed correct tool selection from 400 similar schemas.

Smart teams pick models by task routing: frontier cloud for hard reasoning, local SLM for high-volume classification, mid-tier for cost-sensitive agent loops (Chandra & Krishnamoorthi, 2026). The model is the engine. You do not sell the engine. You sell the car.

Layer 2: Agent (Where the Product Lives)

An agent is not a model with a system prompt. It is a runtime that wraps the model in a loop:

1. Observe context (user message, memory, tool results).
2. Reason and plan next action.
3. Call tools or delegate to sub-agents.
4. Update state, retry on failure, escalate to humans.
5. Repeat until done or bounded.

The agent layer includes components that separate demos from production (MindStudio, n.d.; Agent Operating System, 2026):

• Harness: Retry logic, context management, subagent spawning, evaluators (OpenAI, 2026).
• Memory: Session, user, and org knowledge that survives turns and tabs.
• Orchestration: LangGraph-style workflows with explicit state, not hidden prompt chains (TrueFoundry, 2026).
• Tool discovery: Progressive loading, semantic routing, MCP-Zero-style catalogs instead of dumping 2,800 schemas into context (Xu et al., 2025; Spring AI, n.d.).
• Governance: Human approval gates, policy checks, misalignment monitoring (OpenAI, 2026; OWASP GenAI Security Project, 2025).

Microsoft's Windows agent runtime, OpenAI Codex, and Amazon Bedrock AgentCore all sit at this layer. The model inside can change. The harness is what users and enterprises actually depend on (Microsoft, 2026; Eluna, 2026).

Layer 3: MCP (The Standard Wire)

Before MCP, every agent platform invented its own plugin format. Salesforce had one shape. GitHub Copilot another. Internal platforms a third. MCP replaces that fragmentation with a shared protocol (Model Context Protocol, n.d.).

Three roles:

• Host: The AI application (Cursor, Claude Desktop, Copilot, your agent platform).
• Client: One JSON-RPC client per server connection, inside the host.
• Server: Your integration exposing tools, resources, and prompts.

MCP servers expose:

• Tools: Callable functions (create_ticket, run_query).
• Resources: Readable data (files, database views).
• Prompts: Reusable templates.

The July 2026 spec made remote MCP stateless: no session handshake, no sticky pods. Each HTTP request carries client identity in _meta. Gateways read Mcp-Method and Mcp-Name headers for routing (Model Context Protocol, 2026). That turns MCP from a local dev trick into production infrastructure behind load balancers.

MCP is not the only protocol. Google's Agent-to-Agent (A2A) handles delegation between agents. Many teams use both: MCP for tools, A2A for multi-agent handoffs (Google, n.d.). Think of MCP as USB-C for capabilities. A2A is the office phone system between departments.

Layer 4: Tools (Where State Actually Changes)

Tools are the reason agents matter. A tool call creates a Jira ticket, charges a card, deletes a file, merges a pull request. This is where blast radius lives (Cloud Security Alliance, 2026).

Tools arrive through several patterns in 2026:

• MCP servers: Packaged integrations (official GitHub MCP, internal CRM MCP).
• Agent Connectors: Microsoft Windows on-device registry for File Explorer, Settings, and third-party connectors (Dave R, 2026).
• Native computer use: GPT-6 Astra driving browser and desktop directly, bypassing formal tool schemas for some tasks (OpenAI, 2026).
• Legacy APIs: Wrapped behind MCP servers so agents never touch raw REST (Representational State Transfer) diversity.

Tool design principles that survive production:

• Small surface area. Prefer search_issues and update_issue over one mega-tool that does everything.
• Explicit schemas. Clear names reduce wrong-tool errors when catalogs grow (Spring AI, n.d.).
• Idempotent where possible. Agents retry. Non-idempotent tools need guardrails.
• Backend enforcement. Never rely on the model to respect "do not delete" in the system prompt (Cloud Security Alliance, 2026).

MCPTox showed 72.8% success poisoning tool metadata on real MCP servers. Tool definitions are part of your attack surface, not documentation (MCPTox, 2026).

Layer 5: Infrastructure (Where Trust Is Enforced)

Infrastructure is everything that must work even when the model is wrong. It sits below MCP and tools and enforces reality (Agent Operating System, 2026; Microsoft, 2026):

• Identity and access. Dedicated Non-Human Identity (NHI) per agent, just-in-time credentials, tested revocation (Cloud Security Alliance, 2026; IDC, 2026).
• API gateways. Rate limits, auth, routing for stateless MCP replicas on Kubernetes, Cloud Run, or Lambda.
• Sandboxing. Microsoft Execution Containers (MXC), agent workspaces, cloud PCs for isolated execution (Microsoft, 2026).
• Observability. Tool-call logging with principal, arguments, and outcome to a sink the agent cannot modify (Cloud Security Alliance, 2026).
• Policy engines. Block destructive actions outside declared scope regardless of model intent.
• Data plane. Databases, queues, and secrets stores where tool side effects land.

Eluna runs production warehouse agents on Amazon Bedrock AgentCore with graph-guided Standard Operating Procedure (SOP) execution. The model reasons. The infrastructure guarantees procedural compliance and auditability (Eluna, 2026). That split is the whole point of the five-layer model.

How a Request Flows Through the Stack

Example: "Refund order 4821 and notify the customer."

1. Model parses intent and proposes a plan: lookup order, validate policy, issue refund, send email.
2. Agent loads memory (prior interactions with this customer), checks approval policy (refunds over $500 need human gate), selects tools via discovery (not all 200 schemas).
3. MCP routes tools/call to the Stripe MCP server and the email MCP server with authenticated client identity in _meta.
4. Tools execute: Stripe API refund, CRM status update, SendGrid message.
5. Infrastructure logs each call, enforces OAuth scopes, rate-limits the agent identity, and stores audit records for compliance.

If the model hallucinates a refund amount, infrastructure and tool backends catch it. If MCP metadata is poisoned, gateway inspection and schema pinning catch it. If the agent loops, orchestration checkpoints and budgets stop it. No single layer carries the full burden.

What Breaks When You Skip a Layer

Missing layer	Symptom
No agent layer	Chatbot that cannot sustain multi-step work or recover from failures
No MCP (ad-hoc plugins)	N integrations = N custom wire formats, no shared discovery or audit
No real tools	Agent generates text about actions but nothing in systems of record changes
No infrastructure	Prompt injection becomes data breach; no identity, scale, or kill switch
Model-only focus	Benchmark wins, production losses when tool catalog exceeds context

Real-World Use Cases (Problem → Cause → Effect)

1. IDE assistant that only swapped models

Problem: Team upgraded from GPT-5.6 Sol to GPT-6 Astra expecting 2x productivity. Gains were marginal.

Cause: Harness was unchanged: no parallel sessions, no git worktree isolation, no context notes across windows. Model swap without agent layer investment (OpenAI, 2026; Microsoft, 2026).

Effect: GitHub Copilot app with agent-native harness (parallel sessions, CI babysitting) captured the value. Model was necessary; harness was sufficient.

2. Enterprise MCP behind a load balancer

Problem: Remote MCP worked on localhost, failed in Kubernetes with session errors on the second request.

Cause: Pre-2026 stateful MCP pinned clients to pods. Sticky sessions were fragile (Model Context Protocol, 2026).

Effect: Stateless MCP (July 2026 spec) let any replica serve any request. Infrastructure layer finally matched REST-style deployment patterns.

3. Support agent with 400 tools in prompt

Problem: Agent picked wrong Jira action 30% of the time. Context window half-consumed before user spoke.

Cause: No discovery layer. Model layer alone cannot navigate large catalogs (Spring AI, n.d.; Xu et al., 2025).

Effect: Progressive MCP discovery cut initial context 70 to 90% and improved selection accuracy. Agent layer fix, not model fix.

4. "Local AI" app that synced everything to cloud

Problem: Marketing claimed on-device inference. Security review found customer data leaving the device.

Cause: Model ran locally; agent layer still posted outputs to a cloud analytics endpoint (Beagle, 2026).

Effect: Stack audit required tracing all five layers. Privacy lives in infrastructure and agent design, not model location alone.

Build Order for Teams Starting Today

1. Pick one bounded workflow. Refund processing, ticket triage, code review. Not "general assistant."
2. Wrap it in an agent harness. Explicit state, retries, human gates, memory scope.
3. Expose tools via MCP. One server per domain (billing, CRM, email). Stateless HTTP for production.
4. Implement backend enforcement on tools. Scopes, idempotency keys, rate limits.
5. Add infrastructure before scale. Agent identity, gateway, logging, sandbox. OWASP ASI Top 10 as checklist (OWASP GenAI Security Project, 2025).
6. Choose model last and route by task. Swap freely once layers 2 through 5 are solid.

The new AI stack is not a model picker. It is an architecture:

Model → Agent → MCP → Tools → Infrastructure

The model thinks. The agent acts with memory and policy. MCP connects. Tools mutate real state. Infrastructure enforces trust when the model is wrong, the tool is poisoned, or the agent loops too far.

In 2023, buying GPT access was the strategy. In 2026, the strategy is building layers 2 through 5 so well that the model becomes a replaceable part. The teams winning on agents are not winning on parameters. They are winning on stack discipline.

Map your system against all five layers. Fix the missing floor before you upgrade the engine.

References

• Agent Operating System. (2026). The agent operating system (AOS): A reference operating architecture for distributed agentic systems. arXiv. https://arxiv.org/abs/2608.03214
• Beagle. (2026). Understand Microsoft Aion 1.0 before you plan your deployment. https://www.heybeagle.com/blog/understand-microsoft-aion-1-0-before-you-plan-your-deployment
• Chandra, V., & Krishnamoorthi, R. (2026). On-device LLMs: State of the union, 2026. Meta. https://v-chandra.github.io/on-device-llms/
• Cloud Security Alliance. (2026). Autonomous by design, uncontrolled by default. https://labs.cloudsecurityalliance.org/wp-content/uploads/2026/09/CSA_whitepaper_agentic_ai_loss_of_control_20260908-csa-styled.pdf
• Dave R. (2026). Inside the Windows agent platform. ITNEXT. https://itnext.io/inside-the-windows-agent-platform-how-microsoft-turned-the-os-into-a-secure-runtime-for-1-3-a980ac1d58b0
• Eluna. (2026). Eluna: An agentic LLM system for automating warehouse operations. arXiv. https://arxiv.org/html/2607.08960v2
• Google. (n.d.). Agent2Agent (A2A) protocol. https://google.github.io/A2A/
• IDC. (2026). IDC research finds AI agents outpacing security teams. https://ittech-pulse.com/news/idc-research-finds-ai-agents-outpacing-security-teams-sponsored-by-guidepoint-security/
• Knowlee. (2026). The agentic operating system. https://www.knowlee.ai/blog/agentic-operating-system-business
• MCPTox. (2026). MCPTox: A benchmark for tool poisoning on real-world MCP servers. AAAI. https://ojs.aaai.org/index.php/AAAI/article/view/40895
• Microsoft. (2026). Microsoft Build 2026: Be yourself at work. https://blogs.microsoft.com/blog/2026/06/02/microsoft-build-2026-be-yourself-at-work/
• MindStudio. (n.d.). What is an agentic operating system? https://www.mindstudio.ai/blog/what-is-agentic-operating-system
• Model Context Protocol. (2026). Specification (2026-07-28 stateless update). https://modelcontextprotocol.io/
• Model Context Protocol. (n.d.). Architecture overview. https://modelcontextprotocol.io/docs/concepts/architecture
• OpenAI. (2026). GPT-6 Astra: A new generation of intelligence. https://openai.com/index/gpt-6-astra/
• OWASP GenAI Security Project. (2025). OWASP Top 10 for agentic applications 2026. https://genai.owasp.org/download/52117
• Microsoft Research. (2025). Phi-4-reasoning technical report. https://www.microsoft.com/en-us/research/publication/phi-4-reasoning-technical-report/
• Spring AI. (n.d.). Tool calling and MCP integration. https://docs.spring.io/spring-ai/reference/api/tools.html
• TrueFoundry. (2026). Agent orchestration in production. Referenced via industry deployment patterns.
• Xu, Y., et al. (2025). MCP-Zero: Proactive tool discovery for LLM agents. arXiv. https://arxiv.org/abs/2505.07874

Read More

Why Developers Are Choosing PostgreSQL Over Dedicated Vector Databases in 2026

 

Two years ago, the default move for retrieval-augmented generation (RAG) was obvious: embed your documents, ship vectors to Pinecone or Weaviate, keep PostgreSQL for everything else. Vector databases were built for the job. Postgres was the database your app already had.

That split made sense in demos. In production it often meant two sources of truth, sync pipelines that broke at 2 a.m., and bills that scaled faster than query volume. By 2026, a clear correction showed up: teams with real users, real permissions, and real budgets are moving vectors back into PostgreSQL with pgvector (PostgreSQL Global Development Group, n.d.). Not because vector databases failed. Because most applications never needed a second database in the first place.

What Changed

Three things shifted the default:

• pgvector matured. Hierarchical Navigable Small World (HNSW) indexing, parallel builds, and extensions like pgvectorscale closed much of the latency gap for workloads under roughly 10 to 50 million vectors (BuildSpace, 2026; Kunal Ganglani, 2026).
• RAG became a feature, not the product. Most apps need semantic search plus user rows, billing status, tenant isolation, and deletes that actually stick. That is relational work.
• Operations got honest. Running Postgres you already know beats onboarding a second storage system, new backup rules, and a sync layer nobody wanted to maintain (DBA Dataverse, 2026).

Instacart is the headline example. They consolidated keyword and embedding search into PostgreSQL with pgvector, moving away from a split stack that included Elasticsearch and Facebook AI Similarity Search (FAISS). One engine, one indexing story, finer control over recall (Instacart, 2024; InfoQ, 2025).

The Core Argument in One Sentence

Dedicated vector databases optimize pure approximate nearest-neighbor search at massive scale. Most production apps need search plus business logic in the same transaction. PostgreSQL with pgvector gives you Atomicity, Consistency, Isolation, Durability (ACID), Structured Query Language (SQL) joins, row-level security, and vectors in one place (JusDB, 2026; OpenHelm, 2026).

Use Cases: Problem, Cause, Effect

Below are four patterns we see repeatedly. Each follows the same arc: what broke, why it broke, what teams did instead.

1. Internal document RAG with permissions

Problem: A SaaS (Software as a Service) company built RAG over customer uploads. Users reported seeing snippets from documents they should not access. Incidents were hard to reproduce.

Cause: Document metadata (owner, workspace, delete flag) lived in PostgreSQL. Embeddings lived in a managed vector store. The retrieval path was: vector search first, filter in application code second. Race conditions and stale vectors meant deleted or reassigned documents still surfaced in top-k results. Two systems, no single transactional guarantee (DBA Dataverse, 2026).

Effect after moving to pgvector: One query joins document_chunks to memberships and applies vector distance in the same statement. Deletes are immediate. Row-level security enforces tenant boundaries at the database layer. Incident rate drops because correctness moved from app-side filtering to SQL the database already enforces.

2. E-commerce catalog search (Instacart-style)

Problem: Search returned semantically relevant items that were out of stock or unavailable in the user's region. Shoppers clicked dead ends. Merchandising lost trust in "AI search."

Cause: Semantic retrieval ran against a vector index built from product embeddings. Availability and geo rules lived in PostgreSQL and updated continuously. Pre-filtering in the vector database could not cheaply see realtime inventory without duplicating high-churn fields into embedding metadata or running expensive post-filters (Instacart, 2024).

Effect after consolidating on PostgreSQL: Instacart combined full-text ranking (ts_rank) and pgvector similarity in one datastore, using relational pre-filters (availability, region) before vector scoring. Fewer pipelines, less duplication, better control over how keyword and semantic recall merge (InfoQ, 2025). Search relevance improved because the database saw the same truth the checkout flow used.

3. Startup RAG: prototype cost vs production bill

Problem: A team shipped a Pinecone-backed assistant during beta. At public launch, infrastructure cost jumped faster than revenue. Usage-based pricing on reads and storage compounded with marketing traffic (Rivestack, 2026; Khimananda, 2026).

Cause: The vector tier was priced per dimension stored and per query unit. Beta volume hid the curve. PostgreSQL was already running the app on a fixed instance size. Adding vectors to an existing Supabase or Neon deployment did not add a second vendor invoice line (Moiz Nisar, 2025).

Effect after migrating to pgvector: Predictable monthly database cost, same backup and monitoring stack, no separate sync workers. Latency for their corpus (under two million chunks) stayed within retrieval budget. Money moved from vector SaaS (Software as a Service) fees to one larger Postgres instance they would have scaled anyway.

4. Support ticket semantic search with workflow state

Problem: Support agents searched past tickets by meaning ("payment failed after card update") but results mixed closed, duplicate, and spam threads. Agents wasted time opening irrelevant history.

Cause: Ticket body embeddings sat in Qdrant. Status, assignee, and deduplication keys sat in Postgres. Hybrid filters across systems required two round trips and client-side merging. Metadata drift when tickets were merged or status changed overnight (Kalvium Labs, 2026).

Effect after pgvector: Single query: approximate nearest neighbors on embedding column, WHERE status = 'resolved', WHERE team_id = $1, ordered by similarity. Hybrid keyword plus vector fusion uses PostgreSQL full-text search or pg_trgm in the same engine (Suparbase, 2026). Agent workflow sped up because filters and vectors agreed on row identity.

PostgreSQL vs Dedicated Vector Database

Factor	PostgreSQL + pgvector	Dedicated vector DB
Best fit scale	Roughly under 10 to 50M vectors on a well-provisioned node	100M+ vectors, high query-per-second (QPS), multi-region SLAs
ACID transactions	Yes, native	No (eventual consistency models)
Joins with app data	Native SQL	Metadata filters only; no relational joins
Operational stack	One database to backup, tune, and hire for	Second system plus sync pipeline
Cost model	Fixed instance or managed Postgres tier	Often usage-based; can spike at launch
Hybrid search	Full-text + pgvector + pg_trgm in one query	Varies; Weaviate strong here; others need extras
Sharp edges	HNSW rebuild time, memory tuning, single-node ceiling	Vendor lock-in, limited SQL, sync complexity

What PostgreSQL + pgvector Looks Like in Practice

A minimal production pattern: chunks table, HNSW index, filtered similarity search.

CREATE EXTENSION vector;

CREATE TABLE document_chunks (
  id          bigserial PRIMARY KEY,
  tenant_id   uuid NOT NULL,
  document_id uuid NOT NULL,
  content     text NOT NULL,
  embedding   vector(1536),
  deleted_at  timestamptz
);

CREATE INDEX ON document_chunks
  USING hnsw (embedding vector_cosine_ops);

-- Top 5 similar chunks this tenant may read, excluding soft-deleted rows
SELECT c.id, c.content,
       1 - (c.embedding <=> $1) AS similarity
FROM document_chunks c
JOIN document_access a ON a.document_id = c.document_id
WHERE c.tenant_id = $2
  AND a.user_id = $3
  AND c.deleted_at IS NULL
ORDER BY c.embedding <=> $1
LIMIT 5;

That join and filter in one round trip is the feature vector-only stacks make painful. You can express authorization, lifecycle, and similarity together instead of hoping application code reconciles two stores after the fact.

When a Dedicated Vector Database Still Wins

Postgres is not universal. Stay on or move to Pinecone, Qdrant, Weaviate, or Milvus when:

• You expect 100 million or more vectors with aggressive sub-10 millisecond (ms) latency service-level agreements (SLAs) and horizontal sharding out of the box (BuildSpace, 2026; BackendBytes, 2026).
• Vector search is the product, not a sidebar feature, and you want zero database operations (OpenHelm, 2026).
• You have no PostgreSQL footprint and no appetite to run one just for embeddings (Moiz Nisar, 2025).
• You need multi-region replication managed for you without designing Postgres sharding yourself.
• Your team lacks database operations (DBA) capacity and prefers usage-priced software-as-a-service over tuning HNSW parameters.

The mature view in 2026 is not "vector databases are dead." It is "default to Postgres until metrics prove you outgrew it." Measure recall, p95 latency, and dollars per million queries before you split the stack again.

Decision Checklist

1. Do you already run PostgreSQL for core app data? If yes, pgvector is the path of least resistance.
2. Does retrieval need joins, transactions, or row-level security? If yes, Postgres wins on correctness.
3. Are you under roughly 10 million vectors and moderate QPS? If yes, pgvector performance is usually sufficient.
4. Will launch traffic multiply query cost on a usage-based vector SaaS? If yes, model the bill before committing.
5. Are you building a vector-native product at billion-vector scale? If yes, evaluate dedicated engines with open benchmarks on your embedding size and filter patterns.

Bottom Line

The 2023 playbook was: PostgreSQL for rows, vector database for embeddings, glue in the middle. The 2026 playbook for most teams is simpler: PostgreSQL for rows and embeddings, tune HNSW, add hybrid search where needed, and graduate to a specialized vector store only when scale and SLAs demand it.

Developers are not going back because Postgres is trendy. They are going back because the split stack created sync bugs, permission leaks, and surprise bills. pgvector turns RAG into a database problem teams already know how to solve. For everything else, dedicated vector databases still earn their place at the far end of the scale curve.

Bibliography

• BackendBytes. (2026). Vector databases compared: pgvector vs Pinecone vs Weaviate. https://backendbytes.com/articles/vector-databases-comparison/
• BuildSpace. (2026). PostgreSQL as a vector database: Should you use pgvector or Pinecone for RAG in 2026? https://buildspace.site/blog/postgresql-pgvector-vs-pinecone-rag-2026
• DBA Dataverse. (2026, May). pgvector vs Pinecone vs Weaviate: A production DBA's verdict. https://dbadataverse.com/tech/postgresql/2026/05/pgvector-vs-pinecone-vs-weaviate-a-production-dbas-verdict-2026
• InfoQ. (2025, August). Instacart consolidates search infrastructure on PostgreSQL, phasing out Elasticsearch. https://www.infoq.com/news/2025/08/instacart-elasticsearch-postgres/
• Instacart. (2024). How Instacart built a modern search infrastructure on Postgres. https://www.instacart.com/company/tech-innovation/how-instacart-built-a-modern-search-infrastructure-on-postgres
• JusDB. (2026). Vector databases comparison: pgvector vs Pinecone vs Weaviate. https://www.jusdb.com/blog/vector-databases-comparison-pgvector-pinecone-weaviate-2026
• Kalvium Labs. (2026). pgvector vs Pinecone vs Qdrant vs Weaviate: Which we actually use in production. https://www.kalviumlabs.ai/blog/vector-databases-compared-pgvector-pinecone-qdrant-weaviate/
• Khimananda. (2026). Vector databases for RAG: pgvector vs Pinecone. https://khimananda.com/blog/vector-databases-for-rag-pgvector-vs-pinecone
• Kunal Ganglani. (2026). pgvector vs Pinecone 2026: Full comparison. https://www.kunalganglani.com/blog/pgvector-vs-pinecone
• Moiz Nisar. (2025). Why I skipped Pinecone and used pgvector for my RAG system. https://moiznisar.hashnode.dev/why-i-skipped-pinecone-and-used-pgvector-for-my-rag-system-and-when-you-should-too
• OpenHelm. (2026). Pinecone vs Weaviate vs Qdrant vs pgvector: Vector database showdown. https://openhelm.ai/blog/pinecone-vs-weaviate-vs-qdrant-vs-pgvector
• PostgreSQL Global Development Group. (n.d.). pgvector extension. https://github.com/pgvector/pgvector
• Rivestack. (2026). pgvector vs Pinecone: Which should you use in 2026? https://rivestack.io/blog/pgvector-vs-pinecone
• Suparbase. (2026). pgvector and Postgres for RAG: A 2026 production setup. https://suparbase.com/blog/pgvector-rag-production

Read More