DEV Community: 리브미

Cursor vs GitHub Copilot vs Windsurf: Which AI Editor Fits How You Actually Work?

리브미 — Tue, 04 Aug 2026 15:12:58 +0000

If you want the short version: pick GitHub Copilot if you live inside an existing editor and want AI that stays out of the way; pick Cursor if you want an AI-first editor with an aggressive agent that will rewrite whole files across your codebase; pick Windsurf if you want something between the two — an agent-driven experience with a calmer default posture. The "best" one is mostly a function of how much control you want to hand over, not raw model quality, because all three can route to strong frontier models.

I've spent real time in all three on the same kinds of work — feature additions, multi-file refactors, and the unglamorous debugging that eats most of a day. Here's how they actually differ once the novelty wears off.

What are these three, exactly?

It helps to be precise, because two of these are editors and one is not.

GitHub Copilot is an assistant that plugs into editors you already use — VS Code, Visual Studio, JetBrains IDEs, Neovim, and others. It offers inline completions, a chat panel, and an agent mode that can make multi-step edits. You keep your editor; Copilot is a layer on top.
Cursor is a standalone editor built as a fork of VS Code by Anysphere. Your extensions and keybindings mostly carry over, but the AI is the center of the product: tab completion, an inline edit command, and an agent (Composer) that can plan and apply changes across many files.
Windsurf is also a standalone VS Code–derived editor (from the team formerly known as Codeium). Its headline feature is Cascade, an agent designed to keep track of what you're doing across a session and act on the whole workspace.

The takeaway: Copilot asks you to change nothing about your setup, while Cursor and Windsurf ask you to switch editors in exchange for deeper AI integration.

How do they handle a large, multi-file refactor?

This is where the differences stop being cosmetic.

Copilot's agent mode can span multiple files, but its instinct is conservative. It tends to propose smaller, reviewable diffs and check in more often. That's reassuring on a codebase you don't fully trust the AI with, and mildly annoying when you do want it to just go.

Cursor's Composer is the opposite temperament. Point it at a task like "migrate these components off the old context API" and it will confidently touch a dozen files at once. When it's right, it's the fastest of the three by a wide margin. When it's wrong, you're reviewing a large diff to find where it drifted — and it will occasionally "fix" things you didn't ask it to touch. Cursor's codebase indexing is genuinely good at pulling in relevant files you didn't mention, which is both its best trait and the reason its diffs sprawl.

Windsurf's Cascade sits in the middle. It's agentic like Cursor but tends to narrate its plan and move in slightly smaller increments. In my testing it was less likely than Cursor to make unrequested changes, at the cost of sometimes needing another nudge to finish the job.

Takeaway: for sprawling refactors, Cursor is the fastest and the riskiest; Copilot is the safest and the slowest; Windsurf splits the difference.

Which one is better for everyday completions?

Agents get the headlines, but most of the day is still typing code with an autocomplete looking over your shoulder.

Copilot's inline completion is mature and predictable. It rarely surprises you, which is a compliment — it suggests the obvious next line and gets out of the way. Its ghost-text suggestions feel the most "tuned" across many languages.

Cursor's Tab is more ambitious. It predicts multi-line edits and, notably, your next cursor position, so accepting a suggestion can jump you to the following spot that needs a change. It's excellent during repetitive edits and occasionally too eager, proposing a jump you didn't want.

Windsurf's autocomplete is competitive and closer in feel to Cursor's forward-looking style than to Copilot's minimalism. If you liked Codeium's completion historically, this will feel familiar.

Takeaway: Copilot completion is the least distracting; Cursor's is the most powerful when you're in a repetitive editing groove.

Feature comparison at a glance

Dimension	GitHub Copilot	Cursor	Windsurf
Form factor	Extension for existing IDEs	Standalone editor (VS Code fork)	Standalone editor (VS Code fork)
Agent style	Conservative, incremental	Aggressive, whole-codebase	Middle-ground, narrated
Completion feel	Minimal, predictable	Forward-looking (next edit + cursor)	Forward-looking
Codebase awareness	Good, repo-aware	Strong indexing, pulls unmentioned files	Strong, session-aware
Ecosystem tie-in	Deep GitHub/PR integration	Editor-centric	Editor-centric
Biggest risk	Can feel timid on big tasks	Over-edits, large diffs to review	Occasionally needs re-prompting

When is a paid tier actually worth it?

All three offer a free tier and paid tiers, and the pricing models shift often, so I'll describe the shape rather than quote numbers. As of mid-2026, the pattern across all three is: a free tier with capped usage or slower model access, an individual paid tier that unlocks higher limits and better models, and a team/business tier that adds admin controls and a privacy/no-training guarantee.

The honest guidance:

If you're an occasional user or a student, the free tiers are legitimately usable — start there for all three before paying anyone.
The paid individual tier pays for itself the moment you're using the agent daily for real work; the bottleneck on free tiers is usually request limits on the strongest models, and that's exactly what you hit when the tool becomes part of your workflow.
For teams, the deciding factor is usually policy, not features: whether your code can be excluded from training, and whether you get SSO and audit controls. Check the current terms directly — this is the area most likely to have changed since anything you read secondhand.

Takeaway: don't pay until the free tier's model limits start interrupting you; when they do, the individual tier is an easy yes.

What about privacy and lock-in?

Two things worth weighing before you commit.

On privacy: all three let you opt out of having your code used to train models, but the defaults and the exact guarantees differ by plan, and enterprise controls generally live behind the team tiers. If you work on proprietary code, read the current data-handling terms yourself rather than trusting a comparison post — mine included.

On lock-in: Copilot has the lightest switching cost because you never left your editor. Cursor and Windsurf are editors, so adopting one means your team standardizes on that editor's quirks. Because both are VS Code forks, your extensions largely transfer, but agent configs, rules files, and workflow habits don't move between them cleanly. That's a real, if modest, cost when you switch again later.

Takeaway: Copilot minimizes lock-in by design; the standalone editors trade portability for depth.

Bottom line

Choose Copilot if you value staying in your current IDE, want predictable completions, and lean on GitHub for reviews and PRs — it's the safe default that asks nothing of your setup. Choose Cursor if you want the most aggressive agent available and you're comfortable reviewing large diffs in exchange for raw speed on multi-file work. Choose Windsurf if you want a genuine agent experience with a calmer default and slightly tighter blast radius than Cursor. None of them writes correct code unattended, so whichever you pick, the skill that still matters is reading diffs critically — the tool that makes you best at that is the one you should keep.

pgvector vs Pinecone vs Qdrant: When Is a Dedicated Vector Database Actually Worth It?

리브미 — Tue, 04 Aug 2026 14:54:05 +0000

If you already run Postgres and your corpus is in the low millions of vectors, pgvector is usually the right first choice — one less system to operate, and your filters, joins, and transactions stay in one place. You reach for a dedicated vector database like Pinecone or Qdrant when recall at high query volume, horizontal scale, or operational hand-off starts to hurt inside Postgres. The wrong reason to switch is "everyone else uses a vector DB."

I've shipped retrieval features on all three. What follows is how I actually decide, not a feature matrix scraped from landing pages.

What are you really choosing between?

These three products are not the same category, and treating them as interchangeable is the first mistake.

pgvector is a Postgres extension. It adds a vector column type and approximate-nearest-neighbor indexes (IVFFlat and, in more recent versions, HNSW) to a database you probably already run. It is open source and lives inside your existing Postgres instance.

Pinecone is a fully managed, closed-source vector database delivered as a cloud service. You don't run it; you call an API. Its serverless model separates storage from compute so you're not sizing pods by hand the way the older architecture required.

Qdrant is an open-source vector database written in Rust. You can self-host it (Docker, Kubernetes) or use Qdrant Cloud. It's built around vectors plus rich payload filtering as a first-class concern.

The takeaway: pgvector is a feature of a database you have; Pinecone is a service you rent; Qdrant is a system you can either run or rent.

When is pgvector enough?

For most teams starting out, it is. If your data already lives in Postgres, keeping embeddings in the same database means a retrieval query can filter on tenant_id, join to a users table, and respect the same transaction — no dual-write, no sync job, no "why is the vector store stale" incident at 2 a.m.

A minimal setup looks like this:

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE documents (
  id        bigserial PRIMARY KEY,
  tenant_id bigint NOT NULL,
  content   text,
  embedding vector(1536)
);

-- HNSW index for cosine distance
CREATE INDEX ON documents
  USING hnsw (embedding vector_cosine_ops);

Querying is just SQL, so you combine metadata filters and similarity in one statement:

SELECT id, content
FROM documents
WHERE tenant_id = 42
ORDER BY embedding <=> $1   -- <=> is cosine distance
LIMIT 5;

Where it strains: at higher volumes, the pre-filter-vs-index interaction matters. A restrictive WHERE clause combined with an ANN index can force Postgres to over-scan to fill your LIMIT, hurting recall or latency, and tuning hnsw.ef_search becomes a real exercise. You're also sharing CPU and memory with your transactional workload — a heavy embedding backfill can contend with production traffic. And you own index build times, VACUUM behavior, and memory sizing yourself.

The takeaway: pgvector wins on operational simplicity and query expressiveness until vector search starts competing with your OLTP workload for resources.

When do you actually need Pinecone or Qdrant?

The honest trigger is usually one of three things: scale past what a single Postgres box serves comfortably, query concurrency that demands isolation from your primary database, or a team that wants search to be someone else's operational problem.

Pinecone's pitch is that you never think about the index. No servers, no VACUUM, no HNSW parameters exposed as your problem — you upsert and query. That's genuinely valuable for a small team without a database specialist. The cost is real lock-in: it's closed source and cloud-only, so there's no self-host escape hatch, and your embeddings and metadata live in a vendor you can't run yourself. Pricing is consumption-based, which is efficient at low volume but requires modeling as you grow.

Qdrant sits in between. You get a purpose-built engine with strong metadata filtering, quantization options to cut memory, and the freedom to self-host or use their cloud. The tradeoff is that self-hosting means you're back to running a stateful distributed system — sharding, replication, backups, upgrades. You've traded Postgres operations for Qdrant operations, which is only a win if the vector workload justifies a dedicated system.

Using Qdrant from Python is straightforward:

from qdrant_client import QdrantClient
from qdrant_client.models import Distance, VectorParams, PointStruct

client = QdrantClient(url="http://localhost:6333")

client.recreate_collection(
    collection_name="documents",
    vectors_config=VectorParams(size=1536, distance=Distance.COSINE),
)

client.upsert(
    collection_name="documents",
    points=[
        PointStruct(id=1, vector=embedding, payload={"tenant_id": 42}),
    ],
)

hits = client.search(
    collection_name="documents",
    query_vector=query_embedding,
    limit=5,
)

The takeaway: a dedicated vector DB earns its keep when search scale or isolation is a first-order requirement — not when it's a nice-to-have.

How do they compare at a glance?

	pgvector	Pinecone	Qdrant
Category	Postgres extension	Managed cloud service	Open-source DB (self-host or cloud)
You operate it?	Yes (it's your Postgres)	No	Yes if self-hosted, no if cloud
Source model	Open source	Closed source	Open source
Metadata + joins	Full SQL, joins, transactions	Metadata filters only	Rich payload filtering
Ops burden	Shared with your OLTP DB	Lowest — nothing to run	Dedicated system to run (if hosted)
Best when	You already run Postgres, ~millions of vectors	You want zero ops	You want a purpose-built engine you control
Main drawback	Contends with primary DB at scale	Lock-in, cloud-only	Self-hosting is a real workload

Treat this as a starting hypothesis, then benchmark on your own data — recall and latency depend heavily on dimension count, filter selectivity, and index parameters, none of which a table can capture.

What does the switch actually cost you?

The migration itself is rarely the hard part — re-embedding and bulk-loading a few million vectors is a batch job. The recurring cost is a second system in your architecture: another thing to monitor, back up, secure, keep in sync with your source of truth, and reason about during incidents.

That's the build-vs-buy calculus. Staying on pgvector keeps your surface area small but caps your ceiling. Moving to Pinecone buys away operations at the price of lock-in and a usage bill that scales with success. Moving to self-hosted Qdrant keeps you in control and open source but hands you a distributed database to run. There's no free option — only the tradeoff that fits your team's skills and your workload's real shape.

The takeaway: the meaningful cost of a dedicated vector DB is ongoing operational surface area, not the one-time migration.

Bottom line

Start with pgvector if you already run Postgres and your vector count is in the low millions — you'll ship faster and debug less. Move to Pinecone when you want search to be a managed API and you can accept closed-source lock-in in exchange for near-zero operations. Choose Qdrant when you want a purpose-built, open-source engine and either have the appetite to run it or are happy to pay for their cloud. Whatever you're leaning toward, benchmark on your own corpus with realistic filters before committing — the right answer is workload-specific, and it changes as you grow.