* Add Events page
* Create test
* delete
* A lot of edits
* Change date
* Add-SF-placeholder
* Date edits
* Copy edit
Edited title and added Berlin save the date
* add events link to menus
* fix link
---------
Co-authored-by: Maddie Duhon <madelyn.duhon@qdrant.com>
Co-authored-by: trean <trean.mi@gmail.com>
* Add new Scaling landing page under Operations
Introduces a Scaling section with vertical vs. horizontal scaling
guidance and failover best practices, linking out to detail pages.
* Add new Vertical Scaling page
Dedicated how-to guidance for resizing existing nodes: when to scale
vertically, RAM sizing formulas, and Cloud/self-hosted resize steps.
* Add new Horizontal Scaling and Resilience page
Covers Raft consensus, the replication model, consistency guarantees,
Multi-AZ, and the resilience terminology used elsewhere in the docs.
* Move Distributed Deployment under Scaling and update all incoming links
Moves distributed_deployment.md into the new scaling/ section, trims
its Raft/Replication/Consistency intros into cross-links to the new
Horizontal Scaling and Resilience page, adds Multi-AZ and single-replica
cross-link callouts in the Cloud docs, rewrites all internal references
across ~30 files to the new canonical path instead of relying on
aliases, and applies Title Case to Distributed Deployment's headers.
* Split Resilience out of Horizontal Scaling and Resilience
Adds a dedicated Resilience page covering fault tolerance, Multi-AZ,
resilience terminology, and failover best practices (moved from the
Scaling landing page). Horizontal Scaling is retitled and scoped to
the underlying mechanics: Raft consensus, replication, and consistency.
* Reorganize Horizontal Scaling's structure
Moves "How Many Qdrant Nodes Should I Run?" from Distributed Deployment
into Horizontal Scaling, adds a conceptual Sharding section, and
reorders Sharding/Replication/Raft Consensus/Consistency. Moves the
remaining conceptual content out of Distributed Deployment: Temporary
Node Failure to Resilience, Error Handling folded into Replication,
sharding heuristics folded into Sharding, and the Consensus
Checkpointing explanation folded into Raft Consensus.
* Rename Scaling section to Scaling & Resilience
Renames the section and restructures the landing page: the vertical-
vs-horizontal decision is now purely about scaling, with a dedicated
Resilience section covering fault tolerance through sharding and
multi-node deployments.
* Polish Vertical Scaling and Resilience page content
Reframes Vertical Scaling's "What Not to Do" as positive "Best
Practices". Reworks Resilience's structure: moves the uptime/data-
integrity terminology into the intro as three distinct aspects of
resilience, and renames "How Resilience Works" to "Setting Up a
Resilient Qdrant Cluster".
* Add diagrams illustrating sharding and replication
Adds cluster diagrams to the Sharding and Replication sections on
Horizontal Scaling to make the shard/replica layout easier to follow.
* Add new Node Failure Recovery page
Extracts the node failure recovery scenarios out of Distributed
Deployment into their own page, with each bolded sub-header converted
to a proper heading, and links updated across Resilience and the
Scaling landing page.
* Add new Consistency Guarantees page
Extracts write consistency factor, read consistency, and write
ordering out of Distributed Deployment into their own page, positioned
after Distributed Deployment.
* Add new "Deploy Behind a Load Balancer" section
Explains why a load balancer is needed in front of a multi-node
Qdrant cluster: avoiding a single point of failure at the entry point
and making sure replicas on every node actually serve reads.
* Add new "Rebalancing" section
Documents how Qdrant Cloud automatically rebalances shards across
nodes, as its own subsection under Sharding.
* Rewrite Multi-AZ vs. Replication Factor as Multi-AZ Deployments
Defines an availability zone on first use, explains why multi-AZ
deployments guard against a zone going down, clarifies that Qdrant
Cloud is zone-aware once enabled, and that self-hosted deployments
need to place and move replicas across zones manually.
* Restructure node-count guidance into One/Two/Three-or-more Node subsections
Splits "How Many Qdrant Nodes Should I Run?" into three subsections
and drops the "balanced" framing for two nodes: it states plainly
that two nodes give more capacity without true high availability.
* Add new "Which Configuration Is Right for You?" section
Summarizes the one/two/three-or-more node tradeoffs in one place
right after the detailed breakdown.
* Add explicit _redirects entry for legacy distributed_deployment URL
Closes the redirect chain: the existing /guides/ and /operations/
legacy rules both terminate at /documentation/distributed_deployment/,
which previously had no explicit _redirects entry and only resolved
via the Hugo alias meta-refresh page.
* Fix all incoming links to Distributed Deployment and pages under Scaling
Repoints two same-page anchors in distributed_deployment.md that broke
when Write Ordering moved to Consistency Guarantees, and one link in
cloud/create-cluster.md that broke when a Resilience heading was
reworded.
* Update time-based sharding diagram and restructure section
* Fix a couple of broken links
* Move 'Consensus Checkpointing' to 'Node Failure Recovery' page
The Day 4 large-scale ingestion notebook was the only Essentials Course
demo linking to a personal Google Drive. Repoint it to the versioned
notebook in qdrant/examples so every course notebook lives in one repo.
Notebook added in qdrant/examples#109.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Record the real re-run: parallel 1->4 workers was ~1.2x (5.58s->4.61s) on a
local single node, not 2x. Add the confirmed server version (1.18.2) to both callouts.
- Frontmatter: full-timestamp date, add author_link and keywords, trim description under 140 chars
- Add redirect for the unpublished indexing-optimization article
- Show bits=BITS4 in the TurboQuant snippet to match the decision tree
- Replace the five repeated 'In Python, this can look like' lead-ins with specific ones
- Add prefer_grpc=True tip and a collection-status-green check
Replace the Choosing the Right Mix table with a decision-tree diagram,
refresh all seven strategy diagrams, and group batching, parallelization,
and sharding under Best Practices for Every Upload (no longer numbered options).
Adds a step-by-step tutorial for setting up the Datadog Operator and Agent
to scrape Qdrant metrics via OpenMetrics in Kubernetes-based Hybrid Cloud
and Private Cloud deployments, and links it from the section index and the
operations tutorials table.
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
- Move the "Before we get into..." sentence into the Why Vector Type
Matters section (per Neil's clarified intent)
- Replace all custom-styled inline HTML (vector-type badges, best-fit/
watch-for callouts, benchmark boxes) with standard markdown for
consistency with other articles and docs
- Point to "Qdrant's Agent Skills" at qdrant.tech/documentation/skills/
- Switch Option 3 example from scalar quantization to TurboQuant
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
- Convert all diagram embeds from HTML <img> to markdown image syntax
- Trim code snippets to the focal call (drop client/collection boilerplate;
drop the points-generation block in the batching example)
- Move the "break down the difference" line to open the Vector Type section
- Remove the redundant closing sentence in Why Vector Type Matters
- Bold "there is no single configuration that works best for every bulk upload"
- Replace the Capacity Planning link with the Qdrant sizing calculator
(sizing.qdrant.tech)
- Add a pointer to Qdrant Skills for scenario-specific guidance
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
New production-ops article covering bulk upload best practices in Qdrant:
on-disk vector storage, payload indexes, quantization, sparse-index
on-disk storage, batching, parallelization, and sharding — for both
dense and sparse vectors.
Includes:
- content/articles/bulk-uploads-in-qdrant.md
- Cover / preview / social images (preview/)
- Seven flow diagrams (one per option) illustrating the recommended vs
default path for each strategy
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
