When a pgvector team should migrate to Qdrant and what the move involves
Teams that keep embeddings in PostgreSQL with pgvector often reach a point where search latency, filtered queries or data volume start to strain a database that also serves transactional workloads. At that point, moving vectors to a dedicated engine such as Qdrant is a documented data migration that also changes applications and operations. The effort depends on your schema, the complexity of your filters, the number of vectors and the number of client applications that query them. Qdrant is licensed under Apache-2.0 and the open-source engine is free to self-host, so the spend is on planning, migration, validation and cutover, not on a license.
Start by deciding whether the move is justified. Export a list of the queries your applications run against pgvector and note which ones combine vector similarity with metadata filters, which ones join embeddings to other PostgreSQL tables, and which ones depend on transactional guarantees. Joins and multi-table transactions do not map directly to a vector collection, so each one needs a redesign: move the needed fields into payloads, keep a relational lookup in PostgreSQL, or accept a two-step query. Also confirm the distance metric and vector dimensions used today, because a Qdrant collection must be created with settings that match them before any data moves.
The migration itself covers collection design, data transfer, validation and cutover. Map each pgvector table and its metadata columns to a Qdrant collection and payload schema, then configure the Qdrant Migration Tool's PostgreSQL source with the batch size and parallel workers suited to your table size and database load. Validate by running a sample of production queries against both systems and comparing the returned identifiers and scores, including filtered queries. Plan the cutover as a controlled switch of read traffic with a documented path back to pgvector until the new results are accepted.
Recurring costs move with the platform. Qdrant needs block-level storage with a POSIX-compatible file system, so network file systems and object storage are not suitable as primary storage, and SSD or NVMe drives are recommended. For production, Qdrant's distributed deployment docs recommend at least three nodes so quorum survives a node failure, and a replication factor of 2 doubles storage. When you request a quote, ask for the planning, migration, validation and cutover work as separate line items, the node and storage sizing assumptions, who runs upgrades and backups after cutover, and what is included in a retainer.
What maps cleanly from pgvector to Qdrant and what does not
This table compares the main pgvector concepts with their Qdrant counterparts and marks each as mapping cleanly, mapping with rework, or having no direct equivalent. Use it to scope the schema and query changes before the migration tool moves any data. The main takeaway is that vectors and filterable attributes move well, while joins, cross-store transactions and triggers need a new design.
| Concept | pgvector | Qdrant | Mapping |
|---|---|---|---|
| Container for vectors | Table with a vector column | Collection with vector configuration | Maps with rework |
| Vector column | vector type column per row | Point vector, or named vectors for several embeddings per point | Maps cleanly |
| Distance operator | Operators such as cosine or L2 in ORDER BY | Distance metric set on the collection, confirm options in the Qdrant docs | Maps with rework |
| Non-vector columns | Ordinary typed columns | Payload fields stored as JSON on each point | Maps with rework |
| SQL WHERE filters | Arbitrary SQL predicates | Filters in the query API using supported operators, confirm operator list for your version | Maps with rework |
| Indexes | HNSW or IVFFlat index on the vector column, B-tree on scalars | Vector index per collection, payload indexes on filtered fields | Maps with rework |
| SQL joins | Joins across tables in one query | No joins, denormalize into payloads or query a second store | No direct equivalent |
| Transactional writes | Vector and relational rows committed together | No cross-collection transaction, plan idempotent writes and retries | No direct equivalent |
| Triggers and stored logic | Database triggers on table changes | Application or pipeline logic that runs outside the database | No direct equivalent |
Which documented migration path to use for pgvector
The Qdrant Migration Tool is the documented route for pgvector sources. The cards below cover its pg subcommand and parallel workers, how interrupted runs resume, the client APIs for custom loaders, and the snapshot path for moving data between Qdrant clusters once the data is already in Qdrant.
Qdrant Migration Tool
The Qdrant Migration Tool is the documented route for moving pgvector embeddings into self-hosted Qdrant. It runs as a container or a binary, so it can execute inside the network that holds your PostgreSQL database. It streams data in batches and lists pgvector among its supported sources. Confirm the current source list and version compatibility on the migration tool page before you plan the run.
The pg subcommand
The migration docs name a pg subcommand for reading from PostgreSQL with pgvector. Before running anything, map the source table, the vector column and the identifier and payload columns to the target Qdrant collection fields. Exact flag names and arguments can change between releases, so copy them from the tool page for your version and test against a copy of one table first.
Parallel workers and load limits
The parallel workers option lets the tool read and write several streams at once, which can shorten long runs on large tables. More workers also add load on PostgreSQL and on the Qdrant nodes receiving writes, so agree the setting with the database owner. Confirm the option name, its default and its limits in the migration docs, then watch both sides during a trial run.
Resuming interrupted runs
The tool resumes interrupted runs, which matters when a long load stops because of a network fault, a node restart or a credential rotation. Before the first run, record the source row count and the progress the tool reports, so you can compare totals after a resume. Confirm where the tool keeps its progress state in a container deployment, because losing that state can force a full reload.
Client APIs for custom loaders
Where the tool does not fit, for example when payloads need business-specific transforms or the source schema is unusual (illustrative), your engineers can write a loader with the Qdrant client APIs. This work is one-time build and testing effort, but the loader then needs ongoing ownership by your team. Ask any implementation partner to show how batching, upserts and retries are handled and how counts are verified against the source.
Snapshots between Qdrant clusters
Snapshots move data between Qdrant clusters after the data is already in Qdrant, so they do not read from pgvector. A collection snapshot is a tar archive of a collection on one node, and full-storage snapshots apply only to single-node deployments. Snapshots can be stored in S3-compatible storage since v1.10.0. A snapshot restores only to a cluster on the same minor version or the next minor version, so plan upgrades before the move.
What changes for filtering, payloads and application code
The first decision in a pgvector to Qdrant move is which columns travel with each vector. In pgvector, a query combines a vector distance operator with a WHERE clause over ordinary columns such as tenant_id, document_type, status or created_at. In Qdrant, those columns become payload fields stored alongside each point, and the WHERE clause becomes a filter object evaluated during the search. Each field you filter on should also get a payload index with a matching type (keyword, integer, float, datetime, bool or geo), because unindexed filters on large collections are slow. Review every WHERE clause in the current application and list the columns it uses, the operators it applies and how often each combination runs.
Not every column belongs in the vector store. Large free-text fields, audit history, and data that changes often or is needed only for joins are usually better left in PostgreSQL. The pattern is to keep the point ID equal to the primary key of the relational row, then fetch the remaining fields from PostgreSQL after Qdrant returns the matching IDs. This keeps the Qdrant payload small and preserves transactional updates in the system of record, at the cost of a second read per query. Decide per column, write the decision down, and confirm with the team that owns each table how updates will reach the payload. A column that is copied into Qdrant and then changes in PostgreSQL is a silent source of wrong results.
Application code changes in three places. First, the query layer switches from SQL to the Qdrant client for your language, and it must build filters explicitly instead of composing SQL strings. Point IDs are unsigned integers or UUIDs in Qdrant, so any text key used in pgvector needs a deliberate mapping. Second, pagination changes: offset and limit in SQL are replaced by a scroll call that returns a next page offset, and the application must not assume page numbers are stable. Third, errors and retries differ. Qdrant returns HTTP or gRPC status codes with structured error messages, and writes should be retried idempotently by point ID. Replace any generic database retry wrapper with one that understands these codes and sets timeouts for each call.
Access control also moves. If today the application relies on PostgreSQL roles, row-level security or database users to separate tenants, that logic must be rebuilt. Qdrant offers admin and read-only API keys, and JWT-based access with per-collection read or write permissions, but it does not reproduce row-level security. Confirm the exact permission model against the current Qdrant security documentation for your version, and decide whether tenant isolation will rely on separate collections, a tenant filter enforced by the service layer, or both. Plan how credentials are stored and rotated, and do not expose the Qdrant port until authentication and TLS are configured.
Filtered recall must be tested before cutover. Pick a sample of real queries with their filters, run them against pgvector and against Qdrant with the same embedding model, and compare the top results for each. Pay special attention to selective filters, where a very narrow tenant or date range can return fewer useful neighbors than expected. Record results per filter pattern, not only in aggregate. Use the same test set after the migration tool finishes to catch lost points or payload mismatches. Agree the acceptance threshold with the product owner in advance, and confirm the procedure with your Qdrant partner before the migration window.
The sequence for a pgvector to Qdrant move with a parallel run
This sequence moves embeddings from pgvector into a self-hosted Qdrant cluster while both systems answer queries, so each step is checked against the old results before clients switch. The client keeps data, queries and final approval, and DeployOpen runs the build, the tool runs and the evidence at each gate.
Inventory tables, dimensions, metrics and filters
Catalog every pgvector table and index in scope, including the embedding dimension, the distance operator each index was built for, the payload columns used in WHERE clauses, and the write pattern (bulk loads, streaming inserts, updates or deletes). The client supplies access to schemas, query logs and the owners of each application. DeployOpen produces a migration inventory that maps each source collection to a planned Qdrant collection, with its vector size, distance metric, payload fields to index and expected write load. The step closes when the client has signed off on the mapping, including which filters must be reproduced exactly.
Size and build the target on block storage
Size the Qdrant deployment from the inventory, then provision nodes with local SSD or NVMe block storage with a POSIX-compatible file system. Qdrant cannot run on NFS or S3-style object storage, so this rules out those volumes at the start. The client owns the cloud accounts, data center capacity and network controls. DeployOpen owns the deployment design, the installation, the API key or JWT access setup, TLS and the baseline monitoring, and documents the replication factor and shard count it chose. The step closes when the cluster passes health checks and the client has approved the access model.
Load a pilot collection from a row sample
Create the target collection with the agreed vector size, metric and payload indexes, then migrate a representative sample of rows with the Qdrant Migration Tool's pg subcommand. The sample should include the heaviest filter combinations and the edge cases the inventory flagged, such as null payloads and unusual metadata types. DeployOpen runs the pilot and records any type coercions or dropped fields. The client reviews the pilot against its own queries. The step closes when the pilot collection returns the same top results as pgvector for the agreed test queries.
Run the full migration with the tool
Run the full export from PostgreSQL in batches using parallel workers, with the tool's resume support enabled so an interrupted run can continue without restarting. DeployOpen schedules the run in a window the client approves, watches throughput and errors, and keeps the run log. The client confirms the source database can take the read load and that write activity during the run is either paused or captured for a delta load. The step closes when the tool reports completion with no unresolved batch errors.
Validate counts, payloads and recall
Compare row counts per collection, payload field presence and types, and point IDs between pgvector and Qdrant. Then run a fixed set of query vectors with their filters against both systems and measure recall of the top results against the pgvector baseline. DeployOpen produces a validation report with every mismatch explained, including any payload type changes and any filter that behaves differently. The client accepts the report or sets the recall and mismatch thresholds it needs before cutover. The step closes with a written sign-off of the validation results.
Run a parallel read comparison
Route a copy of live read traffic to both pgvector and Qdrant, return only the pgvector answer to the user, and log the differences in result sets, ordering and latency. Writes continue on pgvector during this period, and the delta since the full load is synchronized to Qdrant on a schedule agreed with the client. DeployOpen builds the comparison harness and the difference dashboards, and the client reviews the mismatches with its application owners. The step closes when the mismatch rate and the causes are understood and accepted by the client.
Cut over application clients
Change each application's vector client configuration to point at Qdrant, one service at a time, with a rollback path that returns reads to pgvector. The client owns the application changes and the release process. DeployOpen supplies the client configuration changes, the runbook, the rollback steps and the post-cutover checks on error rates and recall samples. The step closes when every application reads and writes through Qdrant and the post-cutover checks pass for the agreed observation period.
Decommission old indexes after retention
After the agreed retention period, drop the pgvector indexes and archive or remove the embedding tables according to the client's data retention policy. Keep a verified backup of the source data for the retention period. The client approves the deletion and records it in its change system. DeployOpen removes the indexes, documents what was dropped and confirms the Qdrant snapshot and backup schedule covers the new collections. The step closes with a decommission record that names each table, index and backup location.
What drives the cost and duration of a pgvector migration
This table lists the factors that change the effort and cost of moving embeddings from pgvector to self-hosted Qdrant, and how each one is billed or repeated. Read each row as a question to answer in your own environment before asking for a written quote. The main takeaway is that the vector count matters less than the number of consuming applications, filter patterns and security requirements, which tend to drive most of the rework.
| Driver | Why it changes cost or effort | One-time or recurring | What to ask for in a written quote |
|---|---|---|---|
| Collections and tables | Each pgvector table with embeddings maps to a Qdrant collection that needs its own vector config, payload mapping and validation | One-time | Count of tables in scope, planned collection mapping and who maps each one |
| Vector count and dimensionality | Volume sets migration runtime, storage sizing and snapshot size; dimensionality sets memory and index settings | One-time for the move, recurring for storage | Vector count per table, dimension per collection and the sizing assumptions used |
| Payload complexity | Nested or JSON columns in PostgreSQL must be flattened or re-typed into Qdrant payloads, which adds mapping and test work | One-time | Payload fields to migrate, type conversions planned and how payload rules are tested |
| Filter patterns | SQL WHERE clauses that combine vector search with relational filters must be rewritten as Qdrant filters and indexed payload fields | One-time, with ongoing tuning | List of query patterns in use, which fields need payload indexes and the query rewrite scope |
| Consuming applications | Each service that queries pgvector needs a new client, query translation and a cutover plan | One-time | Number of applications, client language, and whether application changes are in or out of scope |
| Write traffic during the move | Ongoing inserts and updates in PostgreSQL require delta sync or a freeze window, which affects sequencing and test cycles | One-time | How writes are handled during migration, expected write pattern and the delta sync approach |
| Required availability at cutover | A strict availability target usually needs a parallel run, rollback path and extra verification steps | One-time | Acceptable downtime window, rollback plan and whether dual reads are included |
| Deployment model | Single node is simpler; a three-node cluster adds shard, replication and quorum planning; Kubernetes adds chart or operator work | One-time for setup, recurring for infrastructure | Node count, shard and replication settings, Kubernetes distribution and whether the enterprise operator is in scope |
| Security requirements | TLS, API keys, JWT per-collection permissions and audit logging each need configuration, testing and evidence collection | One-time for setup, recurring for key rotation and log review | Which controls are required, who issues certificates and keys, and what audit evidence is delivered |
| Recall acceptance criteria | Defining recall thresholds, test query sets and comparison runs against pgvector determines how much validation is needed | One-time, repeated if results fail | Recall target, test query set size and who signs off the results |
What usually goes wrong in a pgvector to Qdrant migration
Most failed pgvector to Qdrant moves trace back to a few decisions made during setup, before any data is copied. Each card below names one of these decisions, explains why it matters for this migration, and gives the check to run before cutover. Use the list as a pre-flight review for the migration plan.
Running with default settings
According to the Qdrant security documentation, a self-deployed instance listens on all network interfaces and has no authentication until you configure it. Migration jobs and test scripts reach the cluster from the first batch, so an unsecured node can be exposed early. Before the first run, configure admin and read-only API keys, enable TLS for REST and gRPC, and bind the service only to the networks your application needs. Confirm from outside those networks that nothing answers unexpectedly.
Placing storage on NFS or S3
Qdrant needs block-level storage with a POSIX-compatible file system and cannot run on network file systems such as NFS or on object storage such as S3. Teams often reuse a shared volume class because it is already provisioned. Confirm that each node's data volume is local block storage, ideally SSD or NVMe, as the installation documentation recommends. S3-compatible storage can hold snapshots since v1.10.0, but that does not make it valid for live data.
Undersizing the cluster
Qdrant distributed mode uses Raft for cluster topology, and the distributed deployment documentation recommends at least three nodes so quorum survives a node failure. A two-node test layout copied into production has no failure tolerance. Replication also multiplies storage, because a replication factor of 2 doubles the data held for each shard. Size disk and memory from the migrated vector count, payload size and replication factor, choose a shard count that is a multiple of the node count, and ask for these assumptions in writing.
Payload types drifting from SQL types
pgvector tables hold typed columns and often JSONB metadata, while Qdrant stores each point's payload as JSON values that filters match by type. A timestamp stored as text in PostgreSQL arrives as a string, so range filters can behave differently from the SQL comparisons they replaced. Integers stored as floats and arrays flattened into strings cause the same problem. Map every filtered field to an explicit payload type, create payload indexes for filtered fields, and compare result counts for the same filters on a sample.
Silent recall loss
A migration can finish with no errors and still return different nearest neighbors. Typical causes include a distance metric in the Qdrant collection that differs from the one used by the pgvector index, embeddings normalized differently from the source, or query parameters that do not match the old search settings. The job log will not flag any of these. Before cutover, select representative queries, record the pgvector top results for each, and compare the overlap with Qdrant using the same vectors and filters.
Cutover without a rollback path
Switching all application clients to Qdrant in one step leaves no way back if recall or latency is wrong. Keep the pgvector database and its embeddings intact for an agreed window after cutover. Qdrant snapshots restore only to clusters on the same minor version or the next minor version, so a rollback target on another release may reject the snapshot. Take a collection snapshot before cutover, test restoring it on the planned version, and record who decides to switch back and on which measured threshold.
How to validate recall and switch clients without downtime
Validation for a pgvector to Qdrant move should be a set of checks the team agrees on before the first batch runs, with a clear pass or fail result for each. The core checks are row counts per collection, payload spot checks against PostgreSQL, sampled nearest-neighbor comparisons against pgvector results, and filtered query checks. Row counts confirm that every embedding arrived. Payload spot checks confirm that the fields used for filtering, such as tenant identifiers, document status or timestamps, were mapped to the right Qdrant payload keys and types. Neither check says anything about search quality on its own, which is why the sampled comparisons matter most.
For nearest-neighbor comparisons, pick a sample of real query vectors, run each against pgvector and Qdrant with the same top-k, and measure how much the two result sets overlap. Pgvector's exact scan and Qdrant's approximate index will not return identical lists, so the acceptance threshold should be a recall figure agreed in advance, not an expectation of perfect equality. Filtered queries need their own checks, because a filter that works in SQL may behave differently once expressed as a Qdrant payload condition. Include the filters your application actually uses, combined with the same vector queries, and compare results with and without them. Record the Qdrant collection settings used for the index so the results can be reproduced.
The parallel run shadows production reads: the application sends each read to pgvector as before, and also sends a copy to Qdrant, logging both result sets without returning Qdrant's results to users. This exposes latency, error rates and recall drift under live traffic. Writes that arrive during the migration need a decision. A resume approach reruns the tool from a checkpoint so that rows changed after the initial load are picked up by a later pass, while a delta load compares timestamps or change records and writes only what changed. Confirm with your data team how updates and deletes in pgvector are captured, because a plain resume does not remove vectors deleted from PostgreSQL after they were copied.
The cutover is a feature flag in the application that selects which store serves reads and, if the design requires it, writes. The application team owns that flag, the rollback decision and the monitoring that informs it. Keep pgvector running and in sync for a period agreed with the business, so that rollback means flipping the flag back rather than restoring data. Confirm with your Qdrant operations owner that snapshots exist for the target collections before the switch, and rehearse the flip and the rollback in a staging environment that mirrors your production topology.
Acceptance thresholds must be agreed in writing before the parallel run starts. Include the recall threshold, the maximum acceptable latency change, the row count and payload match rules, the filtered query results, and the conditions that trigger rollback. Write down who signs off the cutover and who can call a rollback during the window. An agreed threshold turns a difficult production decision into a check against a number set in advance, which is what keeps the switch from becoming an argument at the moment it matters most.
Questions buyers ask before moving pgvector to Qdrant
How much does it cost to move pgvector data to Qdrant?
The cost is mostly labor, infrastructure and operations, because the open-source Qdrant engine is free to self-host under the Apache-2.0 license. Labor covers schema mapping, running the migration tool, validating search quality and switching application clients. Infrastructure covers the nodes, block storage (SSD or NVMe is recommended) and snapshot storage. Operations recurs after go-live: upgrades, monitoring, backups and on-call support. Costs rise with vector count, embedding dimensions, filter complexity, the number of applications reading from PostgreSQL and whether you need a multi-node cluster. Ask for a quote built from a written scope that lists each of those inputs, and check the Qdrant pricing page for hosted tiers.
How long does a pgvector to Qdrant migration take?
The duration depends on how many collections and vectors you move, how much payload data each point carries, how many services query pgvector today and how much validation your acceptance criteria require. No single figure fits every estate, so ask for a timeline built from the written scope. The migration tool streams data in batches and resumes interrupted runs, so the copy itself is rarely the longest step. Schema decisions, filter re-validation and search quality checks against your test queries usually take more calendar time. Ask the partner to name each milestone, the owner of each one and the criteria that close it.
What does our internal team need to provide for the migration?
Your team provides the source schema and table definitions, read access to the PostgreSQL database, named owners for each application that queries the embeddings, a set of representative test queries with expected results, and written acceptance criteria. You also need the distance metric and embedding model in use, the fields used in filters, and the maintenance windows for cutover. Your DBA should confirm the connection method and the network path from the migration host to PostgreSQL. Without test queries and acceptance criteria, nobody can show that search quality survived the move, so settle those before the build starts.
Can our own team run the pgvector migration with the migration tool?
Yes, in principle. The Qdrant Migration Tool is open source, runs as a container or binary, and lists pgvector among its supported sources. Whether your team should run it depends on PostgreSQL skills, Qdrant operations experience, the time available to validate results and who will own the cutover. A single small collection with a tolerant downtime window is often manageable in-house. Larger or regulated estates usually benefit from a fixed scope with written acceptance criteria. Before planning, confirm the current pg subcommand options, worker settings and flags in the migration tool documentation, since they can change between releases.
Does Qdrant Cloud change the pgvector migration work?
The migration steps stay largely the same, but the target and its controls change. Qdrant Cloud offers a free single-node tier with 0.5 vCPU, 1 GB RAM and 4 GB disk, a usage-priced Standard tier with a 99.5% uptime SLA, and a Premium tier with a minimum spend that adds SSO, private VPC links and a 99.9% uptime SLA. Hybrid Cloud runs managed clusters on your infrastructure, and Private Cloud is a dedicated, fully isolated deployment; both are priced through Qdrant sales. Choose the option based on where data may reside and who operates the cluster, and compare tier limits with your vector count before you migrate.
How do security settings and snapshots fit into a Qdrant migration?
Secure the target before loading data. By default, self-deployed Qdrant listens on all network interfaces and has no authentication, so configure API keys, TLS for REST and gRPC, and JWT-based permissions per collection where applications need different access. JSON audit logging of authenticated API operations has been available since v1.17.0. Take a collection snapshot before cutover and another after validation. Collection snapshots are tar archives of one collection on one node, full-storage snapshots work only on single-node deployments, and snapshots can be stored in S3-compatible storage since v1.10.0. A snapshot can be restored only to a cluster on the same or the next minor version, so plan upgrades with that in mind.
Should we run a multi-node Qdrant cluster after moving from pgvector?
Run a cluster when availability requirements justify the extra nodes and operations. Qdrant's distributed mode uses Raft for cluster topology and collection structure, splits collections into shards across nodes and keeps extra copies through a replication factor. Qdrant recommends at least three nodes for production so quorum survives a node failure, and a shard count that is a multiple of the node count. A replication factor of 2 doubles storage. Qdrant needs block-level storage with a POSIX-compatible file system, so NFS and object storage are not suitable. The community Helm chart lacks enterprise features such as zero-downtime upgrades and automatic shard rebalancing, so weigh that against your upgrade plan. Ask for node sizing in writing.
What changes for filters and payloads when moving from pgvector?
Conditions you wrote as SQL WHERE clauses against PostgreSQL columns become payload filters in Qdrant, so each filtered field must be mapped to a payload key and indexed where needed. Data types, nested values and null handling may behave differently, so test each filter pattern your applications use with expected results. Filters that combine vector similarity with several conditions deserve particular attention because their results can change after the move. Your application owners should confirm which queries they run, how often they run and what result they expect. Confirm the payload indexing options for your Qdrant version in the Qdrant documentation before you finalize the schema.
How DeployOpen scopes, delivers and supports the migration
DeployOpen treats the move from pgvector to Qdrant as a scoped engagement inside infrastructure you control. We agree the scope in writing before work starts, then build, test, document and hand over the migration with your team kept informed at each stage.
How we scope
- We inventory the pgvector tables, embedding dimensions, distance metrics and payload columns that will move to Qdrant collections.
- We confirm which SQL filters must be re-expressed as Qdrant payload filters and which application queries need changes.
- The written scope states deployment target, access model, cutover approach and which deliverables are included before any work begins.
How we build
- We stand up a self-hosted Qdrant environment on block storage, following Qdrant's storage requirements for SSD or NVMe volumes.
- We configure the Qdrant Migration Tool's pg subcommand with parallel workers, batch sizes and resumable runs, then validate record counts against the source.
- We verify retrieval results against sample queries and document the payload and filter mapping for your developers.
How we hand over
- We deliver runbooks covering migration steps, rollback, client connection changes and how to resume an interrupted run.
- We document the Qdrant access configuration, including API keys, TLS and per-collection permissions set during the build.
- We walk your platform and application teams through the operating model so they can run the cluster after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover if your team wants them.
- We can plan snapshot schedules and restore tests, noting that snapshot restores are limited to matching or next minor versions.
- Before any upgrade, we check release notes and confirm the target version with you, since the latest releases change often.
