HDBSCAN vs k-means for clustering customer feedback: which should product and support teams actually use?

If you are sorting thousands of support tickets, survey responses, or product reviews into themes, the short answer is this: HDBSCAN is almost always the better starting point for real-world customer feedback, while k-means remains useful only when you already know how many categories you need, your data lives in a well-behaved vector space, and you want speed above all else. Customer feedback text is messy — it contains noise, duplicates, mixed-topic messages, and clusters of wildly different sizes. HDBSCAN (Hierarchical Density-Based Spatial Clustering of Applications with Noise) was designed for exactly that kind of data, whereas k-means was designed for roughly spherical, similarly sized clusters in continuous numeric space. Below we break down why the difference matters, how to implement each approach in practice, where hybrid pipelines fit in, and what mistakes to avoid when wiring clustering into a feedback triage workflow.

The Direct Answer: HDBSCAN Wins on Real Feedback Data

Also worth reading: What are the best customer feedback tools for SaaS in 2026? · What are feedback attribution modeling templates and how do they improve B2B customer signal analysis in 2026? · How do I build a modern customer feedback scoring model in 2026?

Customer feedback violates nearly every assumption k-means makes. K-means assumes clusters are convex blobs of similar size, that every point belongs to exactly one cluster, and that you can specify k — the number of clusters — in advance. Real feedback corpora break all three assumptions. A typical support inbox might have 40% of tickets concentrated in three dominant themes (billing errors, login failures, API rate limits) while hundreds of minor issues each account for less than 1% of volume. Forcing that distribution into ten equal-ish k-means centroids produces clusters that mix unrelated topics simply because the algorithm must assign every point somewhere.

HDBSCAN takes a different philosophy: it builds a hierarchy of density-based clusters and lets sparse points remain unassigned as noise. In practice, teams running topic discovery over embeddings from models like sentence-transformers routinely find that HDBSCAN isolates coherent micro-themes — say, a spike of complaints about a specific webhook failure introduced in a release two weeks ago — that k-means would smear across several generic clusters. That ability to surface small, dense, actionable groups is precisely what a product team needs when deciding what to fix next.

That said, HDBSCAN is not free of trade-offs. It has hyperparameters (min_cluster_size, min_samples) whose behavior is less intuitive than picking k, it can label a large fraction of points as noise if tuned poorly, and its soft-clustering outputs require extra work to interpret. On very large datasets, naive implementations can be slow, though GPU-accelerated versions such as NVIDIA RAPIDS cuML's DBSCAN/HDBSCAN implementations have reduced runtime dramatically — NVIDIA's developer benchmarks show orders-of-magnitude speedups versus CPU-only scikit-learn on million-point datasets. If you have fewer than 100,000 documents, CPU HDBSCAN with good embeddings typically completes in seconds to minutes anyway.

Why the Difference Matters: How Each Algorithm Actually Works

K-means minimizes within-cluster variance by iteratively assigning points to the nearest centroid and recomputing centroids until convergence. It requires the number of clusters k as input, treats Euclidean distance as the similarity measure, and guarantees every point lands in some cluster. Its time complexity is roughly O(n · k · i · d), where n is the number of points, i the number of iterations, and d the dimensionality — which makes it extremely fast and scalable, even to millions of rows via mini-batch variants.

HDBSCAN extends DBSCAN by converting distances into mutual reachability, building a minimum spanning tree, condensing it into a cluster hierarchy, and then extracting stable clusters that persist across a range of density thresholds. Points that never join a sufficiently dense region get labeled -1 (noise). This density-first design means HDBSCAN finds arbitrarily shaped clusters, handles varying densities, and does not require you to guess the number of themes in advance. Research continues to build on this foundation: recent work such as the LS-BMO-HDBSCAN framework published in Nature combines HDBSCAN-style clustering with memetic bacterial-inspired optimization to improve efficiency on hard datasets, and applied studies — including a SMOTE-PCA-HDBSCAN pipeline for imbalanced water-quality classification, also in Nature — show the pattern of pairing dimensionality reduction with HDBSCAN to handle noisy, skewed data. Those same ingredients (PCA/UMAP reduction plus HDBSCAN) are the standard recipe for feedback text.

The practical consequence: with k-means, your output quality depends heavily on choosing k correctly, and the elbow method or silhouette scores often give ambiguous answers on text embeddings. With HDBSCAN, output quality depends mainly on min_cluster_size, which maps directly to a business question: "how many tickets make a theme worth tracking?" A min_cluster_size of 25 means "only surface themes with at least 25 similar items" — an interpretable dial that non-technical stakeholders understand immediately.

Comparison Table: HDBSCAN vs k-means for Feedback Workflows

Start by converting text to embeddings. Use a sentence embedding model (for example, a MiniLM-class sentence-transformer producing 384-dimensional vectors) so semantically similar tickets land near each other. Then reduce dimensionality before clustering: UMAP reducing to 5–15 dimensions is the community-standard preprocessing step, because HDBSCAN's density logic degrades in high dimensions where distance concentration makes everything look equally far apart. Keep UMAP's n_neighbors around 15 and min_dist near 0 for clustering purposes — you want structure preserved, not a pretty scatter plot.

Next, set min_cluster_size based on corpus size and business relevance. A reasonable heuristic is between 0.5% and 2% of your document count: for 10,000 tickets, try min_cluster_size values of 50–200 and inspect results at both ends. Set min_samples to 1 (the default equals min_cluster_size) if you find too many points labeled as noise; raising it makes clustering more conservative. Expect a first run to leave 10–30% of points as noise — that is normal and often healthy, since noise includes one-off rants, spam, and genuinely unique requests that deserve individual reading rather than forced categorization.

Finally, extract labels per cluster. Two common approaches: run a TF-IDF keyword extraction per cluster (c-TF-IDF, popularized by BERTopic, which uses HDBSCAN internally), or ask an LLM to name each cluster from a sample of 20–30 representative documents. Validate by manually reviewing 10 random members per cluster; if more than about 20% are off-theme, adjust min_cluster_size or your embedding model rather than tweaking endlessly downstream. Teams using a signal-inbox tool like userhero.io can skip most of this plumbing — the platform handles embedding, clustering, and labeling continuously — but understanding these knobs still matters when interpreting why a theme appeared or disappeared after a re-run.

Where k-means Still Earns Its Place

Dismissing k-means entirely would be a mistake. Three scenarios favor it. First, when you already operate a fixed taxonomy — say, 12 support categories mandated by your help-center structure — k-means with k=12 acts as a fast classifier-like assignment step, pushing every new ticket into the nearest existing bucket without leaving anything unfiled. Second, k-means excels as a preprocessing stage: clustering embeddings into 50–200 coarse buckets, then sampling representatives from each bucket, is a cheap way to build diverse training sets or to shrink a corpus before expensive LLM summarization. Third, at extreme scale, mini-batch k-means processes tens of millions of vectors in minutes on modest hardware, whereas HDBSCAN memory usage grows with dataset size unless you move to GPU implementations.

There is also a legitimate hybrid pattern gaining traction in research and industry: over-cluster with k-means (k in the low hundreds), treat each micro-cluster as a "super-sentence," then run HDBSCAN on the centroids. This reduces HDBSCAN's effective input size by 10–50x while preserving local structure, and it echoes the efficiency motivations seen in recent hybrid frameworks like LS-BMO-HDBSCAN. For teams processing hundreds of thousands of feedback items daily, this two-stage approach often delivers HDBSCAN-quality themes at k-means-like cost.

Common Mistakes That Ruin Clustering Results

The most frequent error is clustering raw text or raw high-dimensional embeddings directly. Feeding 768- or 1536-dimensional vectors straight into either algorithm produces mushy results because Euclidean distance loses meaning in high dimensions; always reduce first (UMAP to 5–15 dims for HDBSCAN, PCA or normalization for k-means).

Second, people judge algorithms on the wrong metric. Silhouette score rewards spherical separation and flatters k-means while penalizing HDBSCAN's noise points. For feedback work, the right evaluation is human: sample 10 documents per cluster, check topical coherence, and measure what percentage of volume lands in coherent themes versus noise. A run where 70% of tickets sit in clean themes and 30% is noise beats a k-means run where 100% of tickets sit in 10 mediocre buckets.

Third, teams tune min_cluster_size too low, generating dozens of clusters of 3–5 documents that no one will ever read. If your triage process cannot act on a theme smaller than ~20 items in a week, do not surface it. Fourth, ignoring drift: feedback distributions shift with every release, so a clustering fitted in January may be stale by March. Re-run or incrementally update clusters on a schedule — weekly for most product teams, daily during launch windows. Fifth, conflating cluster count with insight value: 40 precise HDBSCAN themes beat 8 vague k-means buckets, but only if someone owns the queue of themes and closes the loop by routing them to owners. Tools exist to automate the routing; they do not automate the ownership.

When to Act and What It Costs

If your team receives more than roughly 500 pieces of qualitative feedback per month and currently triages by hand or with rigid keyword rules, clustering pays for itself quickly. Manual tagging typically costs a support agent 30–60 seconds per ticket; at 2,000 monthly tickets that is 17–33 hours of labor, versus minutes of compute for automated clustering. Open-source stacks cost nothing but engineering time: Python, sentence-transformers, UMAP, and hdbscan/scikit-learn are all free, and a working prototype takes a competent engineer one to three days. GPU acceleration via RAPIDS cuML requires cloud GPU instances (roughly $0.50–$4 per hour depending on provider and card) but is unnecessary below ~500k documents.

Managed options trade money for time. SaaS feedback-intelligence platforms generally price between $99 and $1,000+ per month depending on seat count and volume, and purpose-built signal-inbox tools occupy the middle of that band. Build-versus-buy math favors building when you have dedicated data engineering capacity and highly custom data sources; it favors buying when the bottleneck is analyst attention rather than infrastructure. Either way, start with a one-week pilot: cluster last month's tickets with HDBSCAN, have a product manager review the top 15 themes, and measure whether the resulting decisions would have differed from the status quo. If yes, invest further; if the themes merely confirm what everyone already knew, your problem is data coverage, not algorithm choice.

The Bottom Line for Product and Support Teams

For exploratory discovery over messy, real-world feedback, HDBSCAN paired with quality embeddings and dimensionality reduction is the default choice, and the evidence base behind density-based clustering keeps growing across domains from audio bioacoustics research presented at AAAI venues to investigative journalism projects like The Marshall Project's recategorization of Justice Department death-in-custody data — both of which faced the same core challenge: unknown category structure hiding in unstructured records. K-means retains a role as a fast, scalable workhorse for enforcing known taxonomies and pre-partitioning huge corpora. The strongest pipelines combine them: k-means for coarse compression and scale, HDBSCAN for fine-grained theme discovery, and a human review loop to convert clusters into shipped fixes. Whichever route you take, evaluate with human coherence checks, revisit parameters quarterly, and remember that the algorithm is the cheapest part of the system — the durable value comes from consistently acting on the themes it surfaces.