Weaviate vs pgvector: when keeping embeddings in PostgreSQL is enough
pgvector is usually the simpler choice when embeddings are a feature of an application that already runs on PostgreSQL. Weaviate fits better when vector search is a service in its own right, shared by several applications and queried through its own collections. The decision turns on five questions: how much filtering each search needs, whether keyword and vector ranking must be fused in one query, whether vectorization should happen at import time through a model provider, how strictly tenants must be isolated, and whether you need replication with tunable consistency. The sixth question is about people: who will patch, back up, tune and on-call each system once it is in production?
Licensing is a note here, not a verdict. pgvector is released under the PostgreSQL License, a permissive license similar to the BSD and MIT licenses, and it adds no separate commercial tier to the extension itself. Weaviate's source outside the wl directory is BSD-3-Clause, but code inside wl is available only under a separate Weaviate enterprise license, and enterprise features are enabled by a license key. Confirm with Weaviate which features your design depends on, so you know whether the BSD core covers them. On the pgvector side, check filtering early: the pgvector repository notes that approximate index scans apply filters after the index is scanned, so a selective filter can return fewer rows than requested unless iterative index scans are enabled and tested against your data.
Before choosing, write down who will run each system. PostgreSQL offers a mature operations model with hot standby servers, synchronous or asynchronous replication and point-in-time recovery, but it does not detect a failed primary on its own, so automatic failover needs external tools described in the PostgreSQL high availability documentation. Weaviate's replication is leaderless, disabled by default and enabled per collection with a replication factor, and its RBAC and OIDC settings are a separate control plane from your database roles. If your team already runs PostgreSQL backups and on-call rotations, pgvector adds little new operational surface. If nobody owns a vector cluster yet, staff that role before adopting Weaviate, and run a proof of concept with your own data volume and filter patterns before committing to either.
Which scenario favors which platform
This table maps common private AI scenarios to the platform that fits better and the condition that decides it. Read each row against your own data model, query mix and operations staff, because the better fit often changes with one of those conditions.
| Scenario | Better fit | Deciding condition |
|---|---|---|
| Existing PostgreSQL application adding semantic search over a modest corpus | pgvector | Embeddings sit beside the rows they describe, and joins, transactions and existing backups already cover them. Keeping one database avoids a second system to secure and operate. |
| RAG service that needs BM25 keyword matching combined with vector similarity | Weaviate | Weaviate combines vector search, BM25 filtering, hybrid search and reranking in one query interface. pgvector needs you to build and tune the keyword side yourself inside PostgreSQL. |
| Multi-tenant SaaS requiring per-tenant isolation in the search layer | Weaviate | Weaviate has built-in multi-tenancy and RBAC with custom roles. With pgvector, isolation usually depends on schema, row-level security or separate databases that your team designs and tests. |
| Team with strong PostgreSQL operations but no vector search experience | pgvector | PostgreSQL backup, upgrade, replication and access controls are familiar. Weaviate adds a new service to patch, back up, scale and monitor. |
| Team with no database operations skills and no PostgreSQL footprint | Depends on the support model | A dedicated vector server adds a component to run, while pgvector still needs a PostgreSQL cluster. Confirm who will handle upgrades, failover and backups before choosing either. |
| Filtered queries where most rows match the filter and recall must stay high | Weaviate | pgvector applies filters after the index scan and needs iterative index scans to recover results when filters remove many candidates. Test recall on your own filters before committing. |
| Large vector collections where index memory and replication targets grow quickly | Weaviate | Weaviate offers horizontal scaling, replication enabled per collection and quantization. pgvector runs on a single PostgreSQL cluster, so capacity planning centers on that cluster's memory and storage. |
| Workloads that need one ACID transaction across vectors and business records | pgvector | Vectors live in the same database as relational data, so inserts and updates can share a transaction. Weaviate is a separate store, so you must design consistency between systems. |
How each system is built and what that means for operations
pgvector and Weaviate solve the same retrieval problem from opposite directions. One adds vector search to a database you may already run, the other adds a dedicated search service with its own APIs and replication. The cards below trace what each design means for backups, upgrades and on-call.
pgvector runs inside PostgreSQL
pgvector is an extension, so embeddings sit in the same cluster, storage, roles and backups as your relational data. A single restore or point-in-time recovery covers both, which simplifies disaster recovery. The trade-off is that vector workloads share CPU, memory and I/O with transactional traffic. Check whether your team already runs PostgreSQL well before adding vector load to it.
PostgreSQL upgrades set the pace
pgvector upgrades follow the PostgreSQL cycle. Minor releases replace executables and restart the server, while major upgrades use dump and restore, pg_upgrade or logical replication. Confirm that your pgvector version supports the PostgreSQL major version you plan to run, and budget a test cycle for each major upgrade. Major versions are supported for five years each, so the window is predictable.
Weaviate is a separate search service
Weaviate runs as its own server with REST, gRPC and GraphQL APIs and official clients. It has its own storage, backups, authentication and upgrade path, so it adds a system to back up, monitor and patch. You can install it with Docker, on Kubernetes or through Weaviate Cloud. Decide early which option your platform team can support on call.
Replication set per collection
Weaviate replication is leaderless and disabled by default. You enable it per collection with a replication factor, then choose ONE, QUORUM or ALL consistency at query time. Stronger levels trade latency and availability for consistency, so agree those settings with application owners. Test node failure in staging before relying on it in production.
Failover needs external tooling
PostgreSQL supports hot standbys with synchronous or asynchronous replication, but it does not detect a failed primary or promote a standby on its own. Automatic failover therefore depends on external tools that your team must select, configure and test. Weaviate's leaderless replication avoids a single primary, which changes the on-call runbook. Ask who owns failover drills for each system.
Access control follows each platform
PostgreSQL authentication covers methods such as SCRAM, certificates, LDAP and OAuth, and roles govern access to tables that hold vectors. Weaviate offers API key and OIDC authentication with RBAC for custom roles. Map who can read, write and administer vectors in each system, and confirm that the chosen identity method matches your directory setup.
Capability, pgvector and Weaviate compared
This table compares the vector search capabilities of pgvector and Weaviate that matter most for a private deployment. Read each row as a question to answer for your own version and workload, since several items depend on how you configure the database. The main takeaway is that pgvector gives exact and approximate search with SQL filters, while Weaviate adds hybrid search, vectorizers, multi-tenancy and replication as built-in server features.
| Capability | pgvector (PostgreSQL extension) | Weaviate (dedicated server) |
|---|---|---|
| Distance metrics | L2, inner product, cosine, L1, Hamming and Jaccard operators | Confirm the metric list for your version and collection settings in the Weaviate docs |
| Index types | Exact search by default, plus HNSW and IVFFlat approximate indexes | Vector indexing is built in; confirm index options and tuning for your release |
| Dimension limits | Vector and halfvec up to 16,000 dimensions; indexing of vector columns up to 2,000 dimensions | Confirm dimension limits for your embedding model and version |
| Hybrid BM25 and vector search | Full-text search comes from PostgreSQL; combining it with vectors is done in SQL | Keyword (BM25) filtering and hybrid search run in one query interface |
| Filtered search | Filtering runs after the index scan; iterative index scans can fetch more rows when filters remove too many | Confirm how filters interact with the vector index for your collection size |
| Built-in vectorizer modules | None; embeddings are generated outside the database and stored as columns | Integrated providers such as OpenAI, Cohere and Hugging Face, or pre-computed embeddings |
| Multi-tenancy | Handled through schemas, tables or row-level design you build and maintain | Built-in multi-tenancy; confirm tenant limits and isolation model for your version |
| Replication and consistency | Inherits PostgreSQL streaming and logical replication; consistency follows the PostgreSQL setup | Leaderless replication, off by default, enabled per collection with ONE, QUORUM or ALL levels at query time |
| Authentication and RBAC | Inherits PostgreSQL methods such as SCRAM, certificate, LDAP and OAuth; roles are PostgreSQL roles | API key and OIDC authentication with RBAC for custom roles; anonymous access is discouraged outside development |
| Horizontal scaling | Scaling is through PostgreSQL replicas, partitioning or separate clusters you design | Built-in horizontal scaling; confirm sharding and node sizing for your workload |
| API surfaces | Standard SQL through any PostgreSQL client or driver | REST, gRPC and GraphQL with official clients for Python, JavaScript/TypeScript, Java, Go and C#/.NET |
What the licenses allow and what is paid for
pgvector is released under the PostgreSQL License, a permissive license that sits alongside the BSD and MIT licenses. The license applies to the extension itself, and the supplied facts list no paid edition or enterprise-licensed feature for pgvector. Internal use, modification and redistribution are permitted under its terms, so a team can run it in its own infrastructure, change it for internal needs and ship it inside another product without a separate commercial agreement. The cost question shifts to the PostgreSQL deployment that hosts it, because PostgreSQL itself is under the same license and its own support windows and operating costs still apply.
- No paid edition in the supplied facts: pgvector has no tiered license or license key that unlocks features, so licensing does not change with scale.
- Permissive terms for internal use: running, modifying and redistributing the extension is allowed under the PostgreSQL License.
- Recurring cost sits in the database: support windows, hosting, backups and staff time for PostgreSQL drive the spend, not the extension.
- Support is contracted separately: any vendor or consultant support for PostgreSQL or pgvector is a services agreement, not a license fee.
Confirm with your legal team that the PostgreSQL License meets your redistribution and attribution requirements, and confirm with your database provider whether any managed PostgreSQL offering adds charges for the extension.
Weaviate uses a split license. Source code outside the repository's wl directory is licensed under BSD-3-Clause, which allows internal use, modification and redistribution with attribution and the license conditions. Code inside wl is available only under a separate Weaviate enterprise license, and enterprise features are enabled by a license key. The boundary is defined by the repository layout, so the question for your team is not whether Weaviate is open source but which of its features depend on the enterprise code path.
- Core under BSD-3-Clause: the code outside
wlcan be used internally, changed and redistributed under BSD-3-Clause terms. - Enterprise code needs a key: features implemented in
wlrequire a Weaviate enterprise license and a license key to run. - Check each feature you need: map hybrid search, vectorizers, multi-tenancy, replication and RBAC against the enterprise boundary before you commit, because the supplied facts do not list which features sit inside
wl. - Licensing recurs, and it is priced by agreement: enterprise terms are negotiated with Weaviate, so the fee and renewal terms are a quote item, not a published figure in these facts.
Ask Weaviate in writing which features in your planned configuration require the enterprise license, and request the license terms before the design is final.
The license boundary matters most when the platform is used inside a company, modified for that company or shipped to customers. Both options allow internal production use at the license level, but the terms differ in what a team may change and redistribute without a separate agreement. Explain this to legal and engineering together, because a modification to a permissively licensed extension and a modification to a license-keyed component carry different obligations.
- Internal production use: both pgvector and the Weaviate core can be run inside your infrastructure under their license terms.
- Modifications: pgvector changes fall under the PostgreSQL License, while Weaviate changes to the BSD-3-Clause core are governed by BSD-3-Clause, and changes that touch enterprise code require the enterprise agreement.
- Redistribution to customers: if your product embeds either system, confirm attribution duties and whether any enterprise component would need separate rights.
- Patches and forks: keeping a fork of the Weaviate core is possible under BSD-3-Clause, but enterprise-licensed behavior still depends on the license key.
- Hosting for third parties: offering either system as a hosted service to outside customers should be reviewed against the license text, not assumed.
Have counsel review the exact license texts for your planned use, especially if the platform will serve external customers.
Costs for both options fall into license fees, infrastructure, implementation services and staff time. For pgvector the license is zero in the supplied facts, so the recurring costs are the PostgreSQL hosting, storage, backups and the staff who operate them. For Weaviate the core license carries no fee in these facts, but enterprise features add a negotiated recurring cost if you need them. Implementation services are typically one-time, while upgrades, support and monitoring recur for either option.
- pgvector recurring costs: database hosting, storage, backup retention and the people who run PostgreSQL.
- Weaviate recurring costs: enterprise license renewals, if enterprise features are required, plus infrastructure for the cluster.
- One-time costs: initial design, data migration, integration with your application and the first security review.
- Cost drivers: the number of enterprise features needed, the number of nodes, and how much your team already runs PostgreSQL.
- Quote items: ask for the license scope, term, renewal rules and what happens to features if the license lapses.
When you request a quote from DeployOpen, the written scope should separate license fees you pay the vendor from implementation work you pay for directly.
Where pgvector's simplicity ends and Weaviate's features begin
pgvector's filtering behavior is the first limit to test. pgvector supports exact search by default and HNSW and IVFFlat approximate indexes, and its README notes that with approximate indexes, filtering is applied after the index is scanned. A query that combines a vector order with a selective WHERE clause can therefore return fewer rows than expected. pgvector offers iterative index scans in strict or relaxed ordering modes to fetch more candidates when filters remove too many, but your team has to tune and verify that behavior for its own query shapes. Run your most selective tenant or category filters against realistic data volumes and check result counts and latency before you rely on the index. Weaviate's data model handles filtering alongside its vector and keyword indexes in one query interface, and its multi-tenancy feature isolates tenant data at the collection level, so the answer depends on how your filters are shaped.
The second limit is resource contention. Storing embeddings in the same PostgreSQL instance as transactional data is simplest when the vector set is modest and the query load is light, because backups, access control and joins all stay in one place. The condition that changes this is memory and CPU pressure: HNSW indexes compete with the buffer cache and working memory that your OLTP workload needs, and a heavy similarity workload can slow order processing or reporting queries. At that point you either size one large instance for both, or move vectors to a system that scales independently. Weaviate's horizontal scaling, sharding through replication settings and vector compression through quantization are built for that second path, but they add a cluster to operate. Ask your DBA to measure index build time and memory on production-like data before deciding.
PostgreSQL already covers much of the operational ground, so do not count these as Weaviate advantages by default. PostgreSQL supports synchronous and asynchronous streaming replication with hot standbys, its client authentication methods include LDAP, certificate and OAuth, and continuous archiving with point-in-time recovery is well documented. What PostgreSQL does not provide is automatic failover: that needs external tooling. Weaviate's replication is leaderless, disabled by default and set per collection with tunable ONE, QUORUM and ALL consistency levels, and its RBAC and OIDC options cover application access. Choose Weaviate when you need per-collection replication behavior, hybrid search and multi-tenant isolation that your PostgreSQL team cannot operate well, and confirm each capability against the current Weaviate documentation before you design around it.
What drives running cost on each side
Running either option costs more than the software line item. The cost follows from where the vectors live, who operates the database, how often you must upgrade, and what support you buy. The cards below set out each driver for Weaviate and pgvector so you can ask the right questions before you request a quote.
Shared database capacity versus a separate service
With pgvector, embeddings add storage, memory and index build load to a PostgreSQL instance that already serves your applications, so the cost shows up as a larger or busier database. With Weaviate, you pay for a second service with its own compute, storage, backups and replicas. Ask for a sizing estimate for both options at your vector count and query rate, and confirm whether that estimate includes the replicas you need for availability.
Existing PostgreSQL skills versus a new system
Teams that already run PostgreSQL can usually extend their backup, monitoring and access processes to pgvector without learning a new query language or storage engine. A team adopting Weaviate must learn its collection model, its API surfaces and its replication settings, and must run that alongside its existing database operations. Count the hours your current DBAs can spare, and ask any services provider to price the training and handover as a separate line.
PostgreSQL major version support windows
Each PostgreSQL major version receives support for a fixed period, and the end dates differ by version, so the upgrade you need may arrive on a schedule set by the community rather than by your project. Major upgrades can run through pg_upgrade, a dump and restore, or logical replication, and each method needs its own rehearsal, rollback plan and testing window. Ask how many upgrades your pgvector estate will need within your planned lifetime and who will carry out each one.
Weaviate release cadence and upgrade testing
Weaviate ships releases on a continuing cadence with maintenance releases on more than one minor line, so your upgrade work recurs whether or not you add features. Each upgrade should be tested against your collections, replication settings, authentication configuration and client libraries before production. Confirm the currently supported release lines and how long each one receives fixes, and ask who will track releases and run regression tests on your side.
Enterprise license and feature costs
Core Weaviate source is BSD-3-Clause, but code in the enterprise directory requires a separate license and enterprise features are enabled by a license key. If your design depends on those features, that license is a recurring cost that pgvector, which is entirely PostgreSQL License, does not carry. Ask in writing which Weaviate capabilities you need are covered by the open core and which need an enterprise license, and whether that license renews annually.
Support and implementation services
Neither option comes with a support contract from the open-source project alone, so vendor support, managed hosting and outside implementation help are separate purchases. DeployOpen plans, implements, hardens, backs up and supports self-hosted platforms in your infrastructure, typically under a written fixed scope with optional retainers for ongoing support and upgrades. Request a written scope that lists the deliverables, the upgrade responsibilities and the handover tasks for whichever option you pick, because no price is published here and a quote follows from that scope.
Moving embeddings from pgvector to Weaviate, or the reverse
This sequence moves vectors and their metadata between pgvector and Weaviate without losing filter behavior or access control. It ends with a cutover you can justify with measured recall and filter results rather than with assumptions.
Inventory collections, dimensions and distance metrics
List every table holding embeddings in pgvector, or every Weaviate collection, with its vector dimension, distance operator (L2, inner product, cosine and so on), row count and the columns used in filters. Confirm each dimension against the target: pgvector indexes vector columns up to 2,000 dimensions, so a higher-dimensional column may need a different index strategy or a reduced model. The output is a signed-off inventory that the migration team and the application owners both accept.
Export vectors and metadata with stable identifiers
Export each record's vector, its scalar payload and a stable identifier from the source system, using a query that runs in a consistent snapshot so counts match the inventory. Keep the identifier as the join key for every later step, including re-embedding and validation. Record the row counts and a checksum per table or collection. The output is a set of export files whose counts and checksums match the source.
Decide what is re-embedded and with which vectorizer
Vectors and payloads transfer unchanged when you keep the same embedding model. Decide per collection whether to keep existing vectors, which is the default for a like-for-like move, or to re-embed using a Weaviate vectorizer module such as an integrated provider. Re-embedding changes every similarity score, so it needs its own recall test and an agreed cost estimate from the provider. The output is a written decision per collection, with the model name and version recorded.
Rebuild indexes, tenancy and replication settings
Create the target structure: Weaviate collections with their replication factor, multi-tenancy setting and quantization, or pgvector tables with an HNSW or IVFFlat index and the chosen distance operator. Replication in Weaviate is disabled by default and must be enabled per collection, so set it deliberately. Load the exported data in batches and confirm object counts per collection or tenant. The output is a populated target whose structure matches the inventory.
Rebuild access control and application query code
Access control does not carry across as data. Recreate API keys, OIDC settings and RBAC roles in Weaviate, or the database roles and grants in PostgreSQL, and map them to the application's identities. Rewrite query code: Weaviate uses its own client libraries and hybrid query interface, while pgvector uses SQL with distance operators. Confirm that each service account can read only its tenant or rows. The output is a tested access matrix and a query layer that passes the existing integration tests.
Validate recall, filters and hybrid results
Run a fixed set of reference queries against both systems, including filtered queries and any keyword or hybrid searches. Compare the top results against an exact search baseline, because pgvector returns exact results by default and approximate indexes can miss neighbors when filters remove many candidates. Check that tenant isolation holds for every collection. The output is a written report of overlap and filter results, with thresholds agreed before the test and any gaps explained.
Cut over and keep a rollback path
Freeze writes or run dual writes for a short, agreed window, apply the final delta, and point the application at the new store. Keep the old store read-only until the new one has run through a full business cycle without incident, and confirm backup and restore for the target before retiring the source. Record the cutover time, the delta counts and the rollback steps. The output is a signed cutover record and a dated decommission plan.
Where implementation projects usually run long
The longest stretches of a Weaviate vs pgvector project are rarely the first deployment. They come from schema and index design, the embedding pipeline, access control and the rehearsals that prove backups and upgrades work. For pgvector, the work centers on the vector column type and its dimension, the choice between exact search and HNSW or IVFFlat indexes, and the table design that sits beside existing relational data. Dimension choice matters because pgvector indexes vector columns only up to 2,000 dimensions, so an embedding model that produces more dimensions changes the index plan. For Weaviate, the work centers on collection definitions, vectorizer configuration (either an integrated model provider or pre-computed embeddings), replication factor per collection and tenant layout. Each option needs a decision on who owns the embedding job, how it is re-run when the model changes, and how failed batches are retried.
Access control and tenant isolation take longer than teams expect. In PostgreSQL, isolation usually means roles, grants, row-level security and the authentication method in pg_hba.conf, and authentication options such as SCRAM, certificates, LDAP or OAuth each need a platform owner. In Weaviate, the team must configure API keys or OIDC, then define custom roles through the RBAC user management API and test them against each tenant. Underestimating this setup is one of the most common delays on both sides. Filter tuning is the other: with pgvector, filtering is applied after the index scan, so teams must test whether iterative index scans are needed when filters remove many candidates. Confirm the expected filter selectivity early, because it drives query design more than raw index speed.
Backup and restore testing and upgrade rehearsal close the project, and both need a dated test plan rather than a checkbox. For PostgreSQL, the documented options are continuous archiving with point-in-time recovery, pg_dumpall, pg_upgrade and logical replication, and each needs a restore drill on a copy of production data. For Weaviate, confirm the backup mechanism for your deployment and the restore steps for a multi-node cluster before go-live. Upgrade rehearsals should cover the pgvector extension version alongside the PostgreSQL major version, since the two move on separate schedules. Ask your implementation partner to write these tests into the statement of work so that acceptance is measured against a restore you have actually performed.
Questions buyers ask before choosing or hiring help
Is pgvector enough for production RAG?
It can be, when your corpus size, query volume, filter patterns and recall targets fit what pgvector handles well. pgvector supports exact nearest neighbor search by default, plus HNSW and IVFFlat approximate indexes. Its README notes that with approximate indexes, filters apply after the index scan, so iterative index scans can fetch more rows when filters remove too many. Check that your embedding dimensions are within the 2,000-dimension limit for indexed vector columns. Weaviate adds built-in hybrid search, multi-tenancy and per-collection replication. Those matter when you need them. Test recall and latency on your own queries before deciding.
What drives the cost of pgvector versus Weaviate?
Both cores are open source, so the main costs are people, infrastructure and any paid features. Recurring costs include hosting, storage, backups, monitoring, PostgreSQL or Weaviate upgrades and on-call time. For pgvector, costs rise with the size of your existing PostgreSQL estate, the memory needed for index builds and the DBA time spent on vacuum and backups. For Weaviate, costs rise with the number of nodes, the replication factor you enable and any enterprise features that need a license key under the enterprise license. Ask any provider for a quote that lists each component, who performs it, and which parts recur.
Can our team run pgvector or Weaviate without outside help?
A team that already operates PostgreSQL with backup, high availability and upgrade routines can usually add pgvector with modest new skills. Weaviate asks for Docker, Kubernetes or Compose experience, plus decisions on authentication, storage and replication. Replication is disabled by default and set per collection, so someone must own those settings. Note that PostgreSQL does not provide automatic failover; you need external tools for that. DeployOpen plans, implements, hardens, documents and supports self-hosted platforms in your own infrastructure, under fixed-scope agreements or retainers. Whether you need that help depends on your skills and your timeline.
How long does a migration from pgvector to Weaviate take, and what drives it?
No general duration applies, because the effort depends on your data and application. The main drivers are the number of collections and tenants, whether you keep your existing embeddings or re-embed with a Weaviate vectorizer, how much SQL filtering moves into Weaviate queries, and how many application clients change. Teams usually run both systems in parallel, compare retrieval quality, then cut over. Pre-computed embeddings are easier to move than data that needs re-vectorizing. Ask for the migration plan, the cutover method and the testing steps in the written scope before accepting any timeline.
Which licenses affect an internal deployment of pgvector or Weaviate?
pgvector is released under the PostgreSQL License, a permissive license similar to BSD or MIT, so internal use carries no source disclosure duty from the extension itself. Weaviate's LICENSE file places code outside the repository's wl directory under BSD-3-Clause. Code inside wl is available only under a separate Weaviate enterprise license, and enterprise features are enabled by a license key. Before you commit, list the features you need and confirm with Weaviate which ones require that key. Your legal team should review the LICENSE files and any commercial terms for your deployment.
What does the work need from our DBA and platform teams?
For pgvector, the DBA owns PostgreSQL version choice, minor updates and major upgrades. PostgreSQL 14 is supported until November 12, 2026, and PostgreSQL 18 until November 14, 2030, so plan the version against those dates. Major upgrades use pg_upgrade, dump and restore, or logical replication, which the upgrade documentation says can work with only several seconds of downtime. The DBA also tunes memory, vacuum, backups and point-in-time recovery. For Weaviate, the platform team typically owns Kubernetes or Compose, storage, network policy, API keys or OIDC, and replication settings. Confirm these responsibilities with each vendor and in your written scope.
How DeployOpen helps you choose and implement
DeployOpen starts with your data volumes, query patterns, tenancy model and existing PostgreSQL estate, then decides with you whether Weaviate or pgvector fits. We plan, implement, harden, document and support the chosen setup inside your own infrastructure, so the decision is made on evidence from your environment rather than on general claims.
How we scope
- Written scope covers which workloads move to each system and which stay in relational tables.
- Scope lists hybrid search, vectorizer, multi-tenancy and replication requirements you actually need.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We deploy the chosen option in your cloud account, data center or air-gapped network.
- Authentication, role setup and backup paths are configured to match your identity and recovery requirements.
- Security testing of the search API and its data access paths runs before go-live where scoped.
How we hand over
- Documentation covers architecture, configuration, upgrade steps and the operating runbook for your team.
- Compliance evidence is prepared for your assessors, who remain responsible for issuing any attestation.
- Knowledge transfer sessions walk your engineers through routine operations and failure recovery.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers cover version upgrades, including PostgreSQL major version moves if pgvector is chosen.
- Revisit the decision with us if data volume or tenancy needs change significantly over time.
