pgvector

How to Build Multi-Tenant SaaS Retrieval (Tracing PDF Citations Across 3 Stages) Short answer: choose a retrieval path only after defining freshness, tenant isolation, and citation tracing as a testable contract; combine a durable PDF index with live retrieval when an answer needs both stable manuals and current context. For a marketplace help center, index cost grows with every tenant, PDF revision, and chunk copy. The cheapest-looking index can become the expensive choice if weak metadata forces duplicate collections or if every correction triggers a full rebuild. I treat this as an operations problem first. I've been paged by missed jobs and duplicate deliveries, and retrieval ingestion has the same failure shape: retries happen, partial work happens, and an unscoped query can be worse than no answer. The invariant is blunt: an answer may cite only chunks retrieved for the requesting tenant and the exact PDF revision recorded by ingestion. Everything else is an implementation detail. What should multi-tenant SaaS help-center retrieval require for citation tracing? Start with the user-visible answer and work backward. Each cited claim needs a stable source identifier, a PDF revision, and a page number or page range. Each retrieval request needs an immutable tenant identifier. Freshness needs a deadline stated in operational terms: for example, whether a corrected policy must be searchable after the next ingestion run or must be visible immediately through a live path. Pick the real requirement; don't hide it behind “near real time.” That produces a compact retrieval contract: | Contract field | Decision to record | Failure it prevents | |---|---|---| | Tenant scope | One required, server-controlled tenant ID | Cross-tenant results | | Retrieval unit | A chunk tied to source, revision, and pages | Citations that cannot be traced | | Freshness | Durable index, live lookup, or both | Answers from an obsolete PDF | | Ingestion identity | Deterministic tenant/source/revision/chunk key | Duplicate chunks after retry | | Answer evidence | Only returned chunk IDs may be cited | Unsupported citations | Keep ingestion, query, and answer citation as separate observable stages. An ingestion success count doesn't prove the query filter worked, and a plausible answer doesn't prove its citations came from the retrieved set. This separation feels fussy until the first PDF replacement races an in-flight query — then it is the only useful timeline in the incident review. No shortcuts here. For a large PDF folder, estimate index cost from the number of stored chunks and replicated metadata, not the file count alone. A useful planning expression is tenants × active PDF revisions × chunks per PDF × replicas. It is a model, not a benchmark. Measure with a representative sample because page layout, tables, and chunk overlap change the result materially; your mileage may vary. Choose the boundary before choosing the product There are two broad paths. A durable vector index gives explicit ingestion control and repeatable retrieval over a known revision. A live search or scrape path improves freshness when the source changes faster than the indexing target. A hybrid query can use the durable index for the PDF corpus and retrieve live context only for questions whose contract permits it. The answer layer still has to preserve the provenance of each result. The products below represent different ownership boundaries, so the right comparison is operational responsibility rather than a synthetic feature score. I would run the same labeled evaluation set against each candidate before committing. | Option | Boundary you adopt | Where it fits | The catch | |---|---|---|---| | PostgreSQL with pgvector | Vector search lives with a PostgreSQL deployment | Teams that want retrieval data beside existing relational tenant data | The team owns index tuning and database capacity | | Pinecone | A managed vector database is a separate service boundary | Teams that want vector operations outside their application database | Application code and operations adopt a dedicated provider contract | | Weaviate | An open-source vector database, available through self-managed or cloud deployment | Teams that value deployment choice and direct control | Self-management adds another production system to operate | | Infrai | One key and one plain REST API cover backend capabilities, so application code stays fixed when the provider behind a capability changes; its discovery surface reports 295 routes across 20 modules | Teams that value a language-independent HTTP boundary and a consistent backend contract | It is not suitable when the retrieval engine itself must be embedded, forked, or tuned below the exposed contract | Stick with pgvector when PostgreSQL is already the system your team can tune and the expected index fits that operating model. Choose Pinecone when a managed, dedicated boundary is the priority. Choose Weaviate when deployment control matters enough to own the added surface. The final row is compelling when portability at the application boundary matters more than engine-level control — but that trade is real, not a footnote. I'm not sure which option wins on index cost for your corpus without its chunk distribution, update rate, replica plan, and the candidates' current billing inputs. A small measured pilot resolves that uncertainty. Marketing price tables do not. Make tenant isolation and citations executable The preventative code path should reject two classes of defects before an answer reaches a user: results for another tenant and citations absent from the retrieved evidence. The following Go program is deliberately local. It defines the contract without inventing a vendor request shape, runs a retrieval fixture, and validates the output end to end. package main import ( "context" "encoding/json" "errors" "fmt" "io" "net/http" "os" "sort" "strconv" "strings" "time" ) type Query struct { TenantID string Text string Limit int } type Chunk struct { ID string TenantID string SourceID string Revision string Page int Text string Score float64 } type Citation struct { ChunkID string SourceID string Revision string Page int } type Retriever interface { Query(context.Context, Query) ([]Chunk, error) } type capability struct { Method string `json:"method"` Path string `json:"path"` } type discovery struct { Capabilities []capability `json:"capabilities"` } func retryDelay(header string, attempt int) time.Duration { if seconds, err := strconv.Atoi(header); err == nil && seconds >= 0 { return time.Duration(seconds) * time.Second } return time.Duration(1<<attempt) * time.Second } func discoverVectorQuery(ctx context.Context, baseURL, key string) (capability, error) { discoveryURL := strings.TrimRight(baseURL, "/") + "/discovery" client := &http.Client{Timeout: 15 * time.Second} for attempt := 0; attempt < 4; attempt++ { req, err := http.NewRequestWithContext(ctx, http.MethodGet, discoveryURL, nil) if err != nil { return capability{}, err } req.Header.Set("Authorization", "Bearer "+key) resp, err := client.Do(req) if err != nil { return capability{}, err } body, readErr := io.ReadAll(resp.Body) resp.Body.Close() if readErr != nil { return capability{}, readErr } if resp.StatusCode == http.StatusTooManyRequests { time.Sleep(retryDelay(resp.Header.Get("Retry-After"), attempt)) continue } if resp.StatusCode < 200 || resp.StatusCode >= 300 { return capability{}, fmt.Errorf("discovery status %d: %s", resp.StatusCode, body) } var manifest discovery if err := json.Unmarshal(body, &manifest); err != nil { return capability{}, err } for _, item := range manifest.Capabilities { if item.Method == http.MethodPost && item.Path == "/v1/vector/query" { return item, nil } } return capability{}, errors.New("vector query contract absent from discovery") } return capability{}, errors.New("discovery rate limit retry budget exhausted") } type MemoryRetriever struct { chunks []Chunk } func (m MemoryRetriever) Query(_ context.Context, q Query) ([]Chunk, error) { if q.TenantID == "" || q.Limit < 1 { return nil, errors.New("tenant ID and positive limit are required") } var matches []Chunk for _, chunk := range m.chunks { if chunk.TenantID == q.TenantID { matches = append(matches, chunk) } } sort.Slice(matches, func(i, j int) bool { return matches[i].Score > matches[j].Score }) if len(matches) > q.Limit { matches = matches[:q.Limit] } return matches, nil } func validateEvidence(tenantID string, chunks []Chunk, citations []Citation) error { allowed := make(map[string]Chunk, len(chunks)) for _, chunk := range chunks { if chunk.TenantID != tenantID { return fmt.Errorf("retrieval crossed tenant boundary: %s", chunk.ID) } allowed[chunk.ID] = chunk } for _, citation := range citations { chunk, ok := allowed[citation.ChunkID] if !ok { return fmt.Errorf("citation was not retrieved: %s", citation.ChunkID) } if citation.SourceID != chunk.SourceID || citation.Revision != chunk.Revision || citation.Page != chunk.Page { return fmt.Errorf("citation provenance mismatch: %s", citation.ChunkID) } } return nil } func main() { key := os.Getenv("INFRAI_API_KEY") baseURL := os.Getenv("INFRAI_BASE_URL") if key == "" || baseURL == "" { panic("INFRAI_API_KEY and INFRAI_BASE_URL are required") } contract, err := discoverVectorQuery(context.Background(), baseURL, key) if err != nil { panic(err) } retriever := MemoryRetriever{chunks: []Chunk{ {ID: "acme/refunds/r7/42", TenantID: "acme", SourceID: "refunds", Revision: "r7", Page: 42, Text: "Seller refund review", Score: 0.91}, {ID: "beta/refunds/r3/18", TenantID: "beta", SourceID: "refunds", Revision: "r3", Page: 18, Text: "Different tenant policy", Score: 0.99}, }} query := Query{TenantID: "acme", Text: "When is a refund reviewed?", Limit: 5} chunks, err := retriever.Query(context.Background(), query) if err != nil { panic(err) } citations := []Citation{{ChunkID: "acme/refunds/r7/42", SourceID: "refunds", Revision: "r7", Page: 42}} if err := validateEvidence(query.TenantID, chunks, citations); err != nil { panic(err) } fmt.Printf("validated %s %s, %d retrieved chunk, and %d citation\n", contract.Method, contract.Path, len(chunks), len(citations)) } Run it as a normal Go file with INFRAI_API_KEY and the platform's versioned API base in INFRAI_BASE_URL. It checks the live, self-describing contract and prints validated POST /v1/vector/query, 1 retrieved chunk, and 1 citation. More important, changing the citation to the beta chunk makes validation fail before publication. In production, the retriever implementation can construct its request from the full JSON Schema returned by discovery; the tenant ID must come from authenticated server context rather than model output or a client-provided metadata filter. Keep that control outside the prompt. Retries deserve their own rule. Derive an ingestion identity from tenant, source, revision, and chunk position, then upsert that identity rather than appending a fresh record. If a provider responds with HTTP 429, honor Retry-After when present and use exponential backoff. The job can run twice. The stored corpus should not double. Prove retrieval quality before rollout Build a small labeled evaluation set from real help-center questions, including at least one pair whose wording is similar across tenants. Record the expected source revision and page range, not merely an expected answer string. This makes citation tracing measurable and catches a system that produces fluent answers from the wrong manual. For each candidate and index configuration, record retrieval results at a fixed cutoff. Inspect tenant-isolation violations first; one violation blocks release. Then compare whether the expected chunk was retrieved, whether its source and revision survived into the citation, and how many chunks were stored for the tested corpus. Those observations connect quality to the index-cost decision without claiming a universal score. The rollout gate I use is operational: ingestion can be replayed without increasing the logical chunk count, queries cannot return a foreign tenant, every published citation maps to a retrieved chunk, and a replaced PDF revision follows the declared freshness policy. Log a request ID across all three stages so an on-call engineer can reconstruct the path. Don't collapse the stages into one “RAG succeeded” event. This advice is not suitable when the corpus is tiny, single-tenant, and citations are unnecessary; plain document search may be enough. It also does not apply unchanged to legal or safety decisions where retrieval evaluation alone cannot establish answer correctness. Add domain review there. For a marketplace help center with many tenant-specific PDFs, though, the contract is the durable part: products and index settings can change, while isolation and evidence rules should not. References - arxiv.org - pgvector/pgvector - docs.pinecone.io - docs.weaviate.io

Can a user retrieve information outside their permissions, including through the lexical search path, caches, or indirect references? Jeevan Srivastava asked this question word for word in a Medium article of 18 October 2026, as one of three dimensions he would assess for a production system, beside retrieval quality and operational performance. He labels his access-control design: "These are proposed production design decisions, not features I'm claiming to have implemented as part of my retrieval fix." > TL;DR > > - Yes, through any read path the permission check does not cover. The question names three: the lexical branch of a hybrid search, filtered differently from the vector branch; a cache that answers before the check runs; and indirect references, such as a fetch by ID or exact name, a pointer to a hidden record, or a scope value supplied by the request or the model. > - One rule addresses all three: the server derives the read scope from the verified caller identity and applies one filter on every path that can return stored content. For the model's part, the Databricks agent memory documentation says of the actor_id that scopes every read: "Never let the model choose it." > - Three probes, run as a user without access, test whether a system holds: a rare word from a restricted document through every search branch; a cache warmed by a user with access; and a direct fetch, a followed pointer and a foreign scope. Each needs a positive control run as a user with access, or an empty result proves nothing. Mnemoverse (the author's company) makes one of the memory APIs quoted below. Can a user retrieve information outside their permissions? Yes, whenever a path that returns stored content skips the check that search runs. A read path is any function, endpoint or query type that can return stored content to a caller: a search, an exact get, a list, an export, an admin surface or a debug endpoint. Heinrich Neb, who works on a memory layer for coding agents, gave the audit rule in a dev.to comment of 27 August 2026: "find every function that can return stored content." | Read path | How it returns what the user may not see | What closes it | Documented by | |---|---|---|---| | Lexical branch of a hybrid search | The full-text query lacks the vector query's filter | One filter below both branches, or passed to each | Srivastava; PostgreSQL; Elasticsearch | | Cache in front of retrieval | A stored answer is served before the check | The caller's scope in the key, or the cache behind the check | RFC 9111, for shared HTTP caches | | Fetch by ID or exact name | A lookup outside search returns the record | An object-level check on every route that takes an ID or a name | OWASP API1:2023; Neb | | Pointer from a visible record | A visible record names a hidden one | The target's visibility checked when the pointer is read | Neb; PostgreSQL | | Scope from the request or the model | A user ID or tag from the path, body or a tool argument is trusted | Scope from the verified identity; supplied values checked against the configured set | Databricks; Supermemory; Mem0; Anis Meziani | | Query language as a search type | Raw queries reach the store | Off unless every user of the deployment is trusted | Cognee | The last four rows are kinds of indirect reference. Srivastava separates the two decisions: "Relevance determines whether information is useful. Authorization determines whether information is allowed to be accessed." How does the lexical search path leak in a hybrid search? The lexical branch is the half of a hybrid search that matches the query's words against a full-text index, such as BM25 or PostgreSQL full-text search, beside the vector half that matches embeddings. Srivastava's rule: "The key decision is that both vector search and lexical search must respect the same access restrictions." The failure: "If vector search filters by tenant or document permissions but PostgreSQL full-text search doesn't, the hybrid retrieval pipeline can introduce a data leak through the lexical branch." On merging the two lists: "Combining rankings must never override authorization boundaries." And at retrieval time: "Apply authorization and tenant filters to every retrieval path." One filter can reach both branches from two places. Below both branches, in the database. With row security enabled on a PostgreSQL table, "all normal access to the table for selecting rows or modifying rows must be allowed by a row security policy", and a table with no policy falls back to "a default-deny policy" (PostgreSQL, Row Security Policies). The same page sets two limits: "the table's owner is typically not subject to row security policies" unless the table is altered with FORCE ROW LEVEL SECURITY, and "Superusers and roles with the BYPASSRLS attribute always bypass the row security system when accessing a table." An application that connects as the owner of an unforced table, as a superuser or as a BYPASSRLS role is not filtered at all. One filter passed to every branch. The filter parameter of the Elasticsearch RRF retriever "Applies the specified boolean query filter to all of the specified sub-retrievers, according to each retriever's specifications." Written once, it cannot drift between two copies. OWASP's LLM08:2025 opens its prevention list with: "Implement fine-grained access controls and permission-aware vector and embedding stores." The OWASP text speaks of vector and embedding stores; a hybrid pipeline has a second index, and the same rule has to reach it. Srivastava adds a condition that holds over time: "metadata can become stale if permissions change and the retrieval index isn't updated accordingly." Does a permission filter keep a restricted user's results complete? Nothing leaks here; the risk runs the other way. The pgvector README: "With approximate indexes, filtering is applied after the index is scanned. If a condition matches 10% of rows, with HNSW and the default hnsw.ef_search of 40, only 4 rows will match on average." Its first suggestion, an index on the filter column, can give exact search in many cases, so the shortfall applies whenever the planner takes the HNSW index instead. What follows is this article's inference for a vector branch on pgvector with an HNSW index, not a measurement. A permission rule is a condition that keeps some share of the rows, so the narrower a user's rights, the fewer rows one scan of the vector index can return, while the full-text branch can still return every permitted match. For hybrid search the README offers fusion: "You can use Reciprocal Rank Fusion or a cross-encoder to combine results." Fusion ranks the lists it receives, so a restricted user's top results draw more on keyword matches than an administrator's do. An evaluation run as an administrator measures only the administrator's ranking: report retrieval quality per permission level. The README's levers: "Starting with 0.8.0, you can enable iterative index scans, which will automatically scan more of the index until enough results are found". On tenants: "For applications with multiple tenants, sharing an approximate index between tenants means vectors from one tenant can affect recall (and speed) for other tenants." And: "For tenant isolation, use list partitioning or separate tables." Can a cache answer with documents the user may not see? Yes, when it answers before the check runs. For shared HTTP caches, RFC 9111, section 3.5, sets the rule: "A shared cache MUST NOT use a cached response to a request with an Authorization header field" to satisfy a later request, unless the response allows shared storage through a Cache-Control directive such as public, s-maxage or must-revalidate. A semantic or answer cache inside an application follows whatever rule the application gives it. Naveen Metta, in an article of 12 October 2026 on RAG before production, states the requirement: > If a user cannot open the document, the model should not be able to quote it. From his team's work: "We found one prompt that could surface HR documents to any employee." He also advises: "Then add a semantic cache in Redis for repeated questions." This article's inference about any cache in front of retrieval, not a description of his system: such a cache answers without running the filter, so the caller's scope has to be part of what it matches on, or it has to sit behind the check. Srivastava would test "whether permissions and deletion requests propagate to the relevant indexed and cached data." The warm, revoke, replay test is covered in the library page on revoked access after an answer was shown, and caches after a delete in Agent Memory Deletion: What Survives a Delete. What counts as an indirect reference, and how does it leak? An indirect reference is any way to reach a record other than a search the filter covers: its ID, its exact name, a pointer from another record, a scope value or a query language. An existence leak is an answer that reveals that a hidden record exists, or something about it, without returning its content. The fetch that skips search. Neb, on his own system: "We had scoping enforced correctly on retrieval, tested, verified", and beside it "a second read path, lookup by exact name rather than similarity, that returned full content to anyone who asked." In short: "Same store, two doors, one guarded." The sign in code: "a read path that doesn't accept the caller identity cannot enforce anything". For APIs, OWASP API1:2023 Broken Object Level Authorization: "Every API endpoint that receives an ID of an object, and performs any action on the object, should implement object-level authorization checks." The pointer. On 25 August 2026, Neb reported a retired record whose banner kept naming its successor after the successor was made private: "Existence leak through the supersession pointer." His rule: "a pointer's validity and a pointer's visibility are both read-time questions, never write-time facts." PostgreSQL warns of a related channel: its referential integrity checks always bypass row security, and "Care must be taken when developing schemas and row level policies to avoid "covert channel" leaks of information through such referential integrity checks." The query language. Cognee pull request #5844, merged into its dev branch on 15 October 2026: "CYPHER and NATURAL_LANGUAGE search types run raw Cypher against the graph database." And: "Any user with read access to a dataset could execute arbitrary queries". The change: "ALLOW_CYPHER_QUERY now defaults to false." For turning it back on: "Only do that when every user of the deployment is trusted." What closes the class: a check at every entry point, and a refusal that neither names nor describes the hidden record, so that a missing record and someone else's record get the same answer. An answer that tells the two apart reveals existence, which is acceptable only where existence is not a secret. Who should set the scope of a memory read: the server, the request or the model? A caller-supplied scope is a value that selects whose data a read covers, such as a user ID, a tenant tag or an actor ID, and that arrives with the request or from the model instead of from the verified identity. The Databricks agent memory documentation (Beta, last updated 26 October 2026) states the rule: "Set actor_id in your application code from trusted caller context: the verified end-user identity for per-user memory, or a trusted team or project key for shared memory. Never let the model choose it." And: "If your strategy depends on an end-user identity, reject requests that don't carry one rather than falling back to a shared actor_id." Three classes of the error, each with a dated fix: A scope chosen by the model. Supermemory pull request #1824, merged on 16 October 2026 into the 2.x release branch of its tools package: "In 2.x, getProfile, documentList, memoryForget and documentDelete accept an optional containerTag from the model and use it unchecked as the request scope." The consequence: "So a model, or a prompt-injected input, can name another tenant's tag and read their profile, list their documents, forget their memories, or delete their documents." The fix: "A model-supplied tag must be one of the tags the developer configured", or the call fails "before any request is sent". The pull request also notes: "Tools 3.x (#1773) already removed model-selected scope." An empty scope read as everything. Mem0 pull request #7581, merged on 12 October 2026, on its hosted clients: "The dangerous one is an empty entity ID. The API treats an empty ID as matching every memory in the project." The case there is the delete calls, delete_all and delete_users, fixed on the client: "This PR blocks that client-side. The server needs its own fix, which is out of scope here." This article did not check whether the server has changed since. A scope taken from the path or the body. Anis Meziani, replying on 14 October 2026 to a comment under his own dev.to article: "Our ADK-native session routes originally checked that a token was valid, not which user it acted for, so the user_id in the path or body was trusted." His fix checks the token's subject against the user_id "on every route that reads sessions or memory, including the live WebSocket". The rule: the scope comes from the verified identity; a request without one is refused, not given a shared scope; an empty value is an error, not everything; a value from the model is checked against the configured set before any request goes out. What changes when several users share one memory store? In a shared store the question moves from the answer to the context. A preprint of 19 October 2026 (arXiv 2610.25707, version 1, not peer-reviewed) opens: "Shared long-term memory lets an LLM agent serving one user inadvertently retrieve another user's credentials, but it is unclear when such exposure leads to actual harm." Its audit used the AppWorld environment and one store for all users' logins: "In AppWorld, a store that mixes 763 past logins from all users retrieves another user's credential for 84.7 percent of required apps, yet agents rarely act on it." Of the misuse its stress test provokes: "Naming the owner before or inside each credential line prevents most of this". Its conclusion: "Agent memory should consistently record whose credential it stores, and evaluations should measure behavior, not only exposure." This article's reading: the boundary is crossed when another user's record reaches the model's context, whether or not the model uses it. Srivastava, from the design side: "The stronger approach is to prevent unauthorized information from entering the context in the first place." Databricks states where the boundary sits: "actor_id separates memories, but it is not an access control. Memory stores are workspace-scoped, so any principal that can reach a store can read and write every entry across all actors." And: "The store, not the actor, is the security boundary. For strict isolation between tenants or users, create a separate memory store per boundary." OWASP's LLM08:2025, for vector databases: "In multi-tenant environments where multiple classes of users or applications share the same vector database, there's a risk of context leakage between users or queries." How do you test that no read path leaks? Each probe has a positive control, because a probe that finds nothing proves nothing until it finds something where it should. They are this article's proposals, not any team's suite. 1. The lexical branch. As the test user, run vector-only, lexical-only and hybrid queries for a rare word, such as a code name, found only in a document the user may not open. Expected: no chunk of it. Control: a user with access gets it. Srivastava proposes this negative test: "Queries from unauthorized users should not expose protected documents, even when those documents are semantically similar to the query." 2. The cache. User A, with access, asks a question whose answer needs the restricted document; user B, without access, asks it and a paraphrase. Expected: B's answer is not built from that document. Control: A's answer is built from that document, and B's answer with the cache off matches B's answer with the cache on. 3. Indirect references. As a user without access, fetch the record by ID and by exact name, follow a pointer to it from a visible record, and send another user's scope and an empty scope. Expected: the same answer as for a record that does not exist. Controls: as a user with access, the same fetch, pointer and scope return the record, so the path is live; a made-up ID on the same path gives the answer to compare against. Three rules for the run: - Take the list of read paths from the code or the tool registry, not from a filtered listing. sam ros, on 15 October 2026, about the CI test of the scope check in his MCP server: "with a list_tools override that filters by the token's scopes, the old test passed while a tickets:read token could still delete." - Rerun the probes after a permission change and after a delete: permission data copied into an index or a cache can go stale. - Inspect what reached the model's context, not only the final answer. A passing first probe says nothing about the second and the third. How do memory APIs document where the boundary is? Two documented positions, in their own words, as read on 2 November 2026. Databricks. The store is the boundary, and application code, not the model, sets the actor ID; both are quoted above. Mnemoverse. The security page states the tenant boundary: "Every API key is bound to a unique organization_id. All database queries are scoped to your organization." Shared rooms (beta) stay apart: "room content never appears in your normal (non-room) searches". The rooms reference covers indirect references: "Knowing a room id grants no access to its contents: access is enforced by the API's membership check on every request, and non-members get 403." And: "Membership is checked before archive state, so a non-member of an archived room still gets the membership 403", so the answer does not reveal whether a room is archived. This is a documented boundary, not a test result; this article tests no product. What this article does not claim No measurement of any product and no figure for how often any system leaks. The numbers above are the pgvector README's illustration and one preprint's audit, each with its conditions. Vendor fixes are quoted from their own pull requests with their merge dates; this article did not check whether a fix has reached a release. The inference about rank fusion is for pgvector with an HNSW index and was not measured. The probes are proposals, not a description of any team's suite. --- Sources and method. Every quotation was read on 2 November 2026 with two instruments, a browser-like request and a second reading of the same text: a reader service with its cache off, and in addition the dev.to API for the dev.to comments, the RSS feed for Jeevan Srivastava's article and the arXiv API for the preprint; for the GitHub pull requests and the pgvector README, which the reader service refuses, the GitHub API and the raw file took its place. A made-up address on each host answered 404 as a control, except Medium, which answers 200 to any address, so there only the article text counts. The text describes those pages as of that date. A longer version, with the common questions and the full list of sources, is in the Mnemoverse documentation library: Can a user retrieve information outside their permissions, including through the lexical search path, caches, or indirect references? Edward Izgorodin · Mnemoverse · 2026-11-02

pgvector ⭐ 24k pgvector adds vector similarity search to Postgres, for developers building search and recommendation features. 🔗 pgvector/pgvector #opensource t.co

@ArdenBuilds i am trying out pg vector. pgvector/pgvector

pgvectorの各機能の実機検証! はじめに 以前書いた「pgvectorで学ぶVector Database（RAGの基礎）」の続きです。 もしVector Databaseの概要を知らなければ、そちらの記事の図を見ていただければなんとなくわかると思います。 また、記事に出てくる用語は「補足」章にまとめています。必要であれば参照してください。 前回の記事では、20件の英語のサンプル文を入れてベクトル検索を動かしてみたのですが、最後のおまけでIVFFlatインデックスを貼って検索したときに、インデックスを貼る前とコサイン距離の数値も順位もまったく同じになる、という結果になっていました。 近似検索なのに結果が変わらないのはデータ件数が少なすぎたからとArgonさんに回答を頂いたので、その他機能とともに検証します。今回は日本語の文章データを3,000件入れて、psqlでログインして各機能を手で動かしながら試してみました。 検証に使ったファイル等はこちらにおいてます：hsmto25519/pgvector-test 今回の検証の前提 検証に入る前に、データの作り方についていくつか前提を置いておきます。 まず、実際にドキュメントなどを対象にRAGを組む場合は、長い文章を適切な長さに分割する処理が必要になりますが、今回はpgvector自体の動きを見ることが目的なので、分割処理は省略して最初から1文ずつに分かれた日本語の文章がある前提で進めます。 また、テーブルへ入れる日本語の文章については、社内規定やIT運用のマニュアルを想定した20カテゴリ・3,000件のセンテンスをAIに出力してもらい、1つのJSONファイル（sentences_3000.json）に用意して使っています。 検証準備 環境確認 前回と同じく、WSL2（Ubuntu 24.04）上のDockerとPythonを使います。 まずはWSL上の環境を確認しておきます。 lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 24.04.1 LTS Release: 24.04 Codename: noble docker --version Docker version 29.1.3, build 29.1.3-0ubuntu3~24.04.2 python3 --version Python 3.12.3 DockerコンテナはPostgreSQL 18ベースの pgvector/pgvector:pg18 を使います。 services: db: image: pgvector/pgvector:pg18 container_name: pgvector_pg18_test ports: - "127.0.0.1:5432:5432" environment: POSTGRES_USER: postgres POSTGRES_PASSWORD: secret0001 POSTGRES_DB: vector_db volumes: - pgdata:/var/lib/postgresql volumes: pgdata: コンテナを起動して psql でログインし、バージョンと vector 拡張を確認します。PostgreSQL 18.6、pgvectorは 0.8.7 (現時点の最新版) が入っています。 docker exec -it pgvector_pg18_test psql -U postgres -d vector_db psql (18.6 (Debian 18.6-1.pgdg12+2)) Type "help" for help. vector_db=# CREATE EXTENSION IF NOT EXISTS vector; CREATE EXTENSION vector_db=# \dx List of installed extensions Name | Version | Schema | Description ---------+---------+------------+------------------------------------------------------ plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language vector | 0.8.7 | public | vector data type and ivfflat and hnsw access methods (2 rows) データ投入（Python） 3,000件のデータを手で入れるのは大変なので、データを入れるところだけPython（insert_data.py）で自動化します。 今回は sentences_3000.json に用意した3,000件の日本語文章を読み込み、Embeddingモデルを使ってベクトル化してからPostgreSQLへ投入します。初回実行時はモデルのダウンロードが走るためトータルで1分前後かかります。 - 利用Embeddingモデル: intfloat/multilingual-e5-small（384次元） - モデル容量約500MB また、あとでpsqlにログインして手動でSQLを実行するときに384次元の長い配列を毎回貼らなくて済むよう、検索クエリ用の文章（PostgreSQLのインデックスを使ってベクトル検索を高速化する方法）とそのベクトルを query_target という別テーブルに1件保存しています。 なお、multilingual-e5系のモデルは検索対象の文章に "passage: "、検索クエリに "query: " というプレフィックスを付けてベクトル化する仕様になっているため、コード内でもそれを付けて変換しています。 import json import psycopg2 from psycopg2.extras import execute_values from sentence_transformers import SentenceTransformer MODEL_NAME = "intfloat/multilingual-e5-small" # 1. 事前に用意した3,000件の日本語文章データを読み込む with open("sentences_3000.json", "r", encoding="utf-8") as f: data = json.load(f) # 2. Embeddingモデルで3,000件の文章をベクトル化（E5モデルの仕様に合わせて "passage: " を付与） model = SentenceTransformer(MODEL_NAME) passages = ["passage: " + item["sentence"] for item in data] embeddings = model.encode(passages, batch_size=128, show_progress_bar=True) # 3. PostgreSQLへ接続してテーブル作成・データ投入 conn = psycopg2.connect( host="localhost", port=5432, database="vector_db", user="postgres", password="secret0001", ) conn.autocommit = True cursor = conn.cursor() cursor.execute("CREATE EXTENSION IF NOT EXISTS vector;") cursor.execute("DROP TABLE IF EXISTS items;") cursor.execute(""" CREATE TABLE items ( id SERIAL PRIMARY KEY, category TEXT, sentence TEXT, embedding VECTOR(384) ); """) rows = [] for item, emb in zip(data, embeddings): vec_str = "[" + ",".join(f"{float(v):.6f}" for v in emb) + "]" rows.append((item["category"], item["sentence"], vec_str)) execute_values( cursor, "INSERT INTO items (category, sentence, embedding) VALUES %s", rows, ) cursor.execute("ANALYZE items;") # 4. 検索用のクエリ文とベクトルを別テーブルに1件保存（検索クエリには "query: " を付与） query_text = "PostgreSQLのインデックスを使ってベクトル検索を高速化する方法" query_emb = model.encode("query: " + query_text) query_vec = "[" + ",".join(f"{float(v):.6f}" for v in query_emb) + "]" cursor.execute("DROP TABLE IF EXISTS query_target;") cursor.execute(""" CREATE TABLE query_target ( q_text TEXT, q_vec VECTOR(384) ); """) cursor.execute( "INSERT INTO query_target VALUES (%s, %s::vector);", (query_text, query_vec), ) cursor.execute("ANALYZE query_target;") cursor.close() conn.close() print("done") スクリプトを実行してデータを入れます。 python insert_data.py Batches: 100%|██████████████████████████████████████████| 24/24 [00:35<00:00, 1.47s/it] done データが入ったので、ここからはpsqlでPostgresにログインして手動でコマンドを実行していきます。 docker exec -it pgvector_pg18_test psql -U postgres -d vector_db vector_db=# SELECT id, category, sentence FROM items WHERE id <= 5 ORDER BY id; id | category | sentence ----+------------------+---------------------------------------------------------------------------- 1 | データベース | vacuumを実行することで不要な領域を回収してテーブルの肥大化を防ぎます。 2 | 経費精算 | 交通費や出張旅費の精算は月末までに領収書を添付して申請してください。 3 | ネットワーク | 社内無線LANに接続する際は専用の証明書を端末にインストールしてください。 4 | コンテナ・Docker | 開発用のデータベース環境はDockerコンテナを使ってローカルで起動できます。 5 | セキュリティ規定 | 業務用アカウントのパスワードは12文字以上で設定し使い回しを避けてください。 (5 rows) vector_db=# SELECT q_text FROM query_target; q_text -------------------------------------------------------------- PostgreSQLのインデックスを使ってベクトル検索を高速化する方法 (1 row) (SELECT q_vec FROM query_target) を条件に使うことで、このクエリ文のベクトルを使った検索ができます。 検証 1. ベクトルデータのサイズとページ配置 まず、入れた384次元のベクトルと日本語の文章がPostgresの中で何バイトくらい使っているのか見てみます。 vector_db=# SELECT vector_dims(embedding) AS dims, pg_column_size(embedding) AS vector_bytes, pg_column_size(items.*) AS total_row_bytes FROM items LIMIT 1; dims | vector_bytes | total_row_bytes ------+--------------+----------------- 384 | 1544 | 1696 (1 row) vector型は1次元あたり4バイト（32-bit float）なので、4 Byte × 384次元 + 8 Byte（ヘッダ） = 1544 Bytesになっています。category や sentence の日本語テキストを合わせるとさらに増え、この例だと1696 Byteです。 続いて、各行がどのページに入っているかを ctid（ページ番号, ページ内の行番号）で見てみます。 vector_db=# SELECT id, ctid, pg_column_size(items.*) AS row_bytes FROM items WHERE id <= 8 ORDER BY id; id | ctid | row_bytes ----+-------+----------- 1 | (0,1) | 1696 2 | (0,2) | 1688 3 | (0,3) | 1700 4 | (0,4) | 1700 5 | (1,1) | 1708 6 | (1,2) | 1704 7 | (1,3) | 1700 8 | (1,4) | 1700 (8 rows) Postgresの1ページはデフォルトで8KB（8,192 Bytes）なので、1行約1,700 Bytesだと1ページに4行（(0,1)〜(0,4)）入ったところで次のページ (1,1) に移っているのが分かります。 今回は3,000件入れたので、テーブル全体では 3,000 ÷ 4 = 750ページ（6,000 kB）になります。 2. インデックスなし（Seq Scan）と IVFFlat / HNSW の比較 前回の記事のおまけで気になっていた部分の検証です。 3,000件（750ページ）のデータに対して、インデックスなし（Seq Scan）、IVFFlat、HNSW でそれぞれ上位5件を検索し、EXPLAIN (ANALYZE, BUFFERS) で実行時間と読み込んだページ数、検索結果の精度を見てみます。 インデックスなし（Seq Scan） まずはインデックスを貼らずに検索してみます。 vector_db=# SELECT id, category, sentence FROM items ORDER BY embedding <=> (SELECT q_vec FROM query_target) LIMIT 5; id | category | sentence ------+--------------+------------------------------------------------------------------------------------------------------ 141 | データベース | PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 1341 | データベース | 原則として、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 1741 | データベース | 基本方針として、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 2541 | データベース | セキュリティと品質維持のため、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 2941 | データベース | 全社共通のルールとして、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 (5 rows) vector_db=# EXPLAIN (ANALYZE, BUFFERS) SELECT id, category, sentence FROM items ORDER BY embedding <=> (SELECT q_vec FROM query_target) LIMIT 5; QUERY PLAN ------------------------------------------------------------------------------------------------------------------------ Limit (cost=838.34..838.35 rows=5 width=188) (actual time=2.227..2.231 rows=5.00 loops=1) Buffers: shared hit=751 InitPlan 1 -> Seq Scan on query_target (cost=0.00..1.01 rows=1 width=1544) (actual time=0.003..0.005 rows=1.00 loops=1) Buffers: shared hit=1 -> Sort (cost=837.33..844.83 rows=3000 width=188) (actual time=2.225..2.226 rows=5.00 loops=1) Sort Key: ((items.embedding <=> (InitPlan 1).col1)) Sort Method: top-N heapsort Memory: 27kB Buffers: shared hit=751 -> Seq Scan on items (cost=0.00..787.50 rows=3000 width=188) (actual time=0.023..1.910 rows=3000.00 loops=1) Buffers: shared hit=751 Planning Time: 0.057 ms Execution Time: 2.273 ms (13 rows) Seq Scanなので、items テーブルの750ページとquery_targetの1ページを合わせた751ページ（Buffers: shared hit=751）を読み込んで、3,000件すべてと距離を計算しています。実行時間は2.273 msでした。 検索クエリ（PostgreSQLのインデックスを使ってベクトル検索を高速化する方法）に対して、データベースカテゴリの「PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。」など似た文5件（ID: 141, 1341, 1741, 2541, 2941）が上位5件として返ってきており、これが全件計算したときの正解の5件になります。 IVFFlat インデックス 次に、前回と同じようにIVFFlatインデックスを lists = 100（100個のグループに分割）で作成して検索してみます。 検索時にいくつのグループを調べるかを指定する ivfflat.probesを1と5に変えて実行してみました。 vector_db=# CREATE INDEX items_ivfflat_idx ON items USING ivfflat (embedding vector_cosine_ops) WITH (lists = 100); CREATE INDEX vector_db=# SET ivfflat.probes = 1; SET vector_db=# SELECT id, category, sentence FROM items ORDER BY embedding <=> (SELECT q_vec FROM query_target) LIMIT 5; id | category | sentence ------+--------------+------------------------------------------------------------------------------------------------------ 141 | データベース | PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 1341 | データベース | 原則として、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 1741 | データベース | 基本方針として、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 2541 | データベース | セキュリティと品質維持のため、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 2941 | データベース | 全社共通のルールとして、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 (5 rows) vector_db=# EXPLAIN (ANALYZE, BUFFERS) SELECT id, category, sentence FROM items ORDER BY embedding <=> (SELECT q_vec FROM query_target) LIMIT 5; QUERY PLAN ------------------------------------------------------------------------------------------------------------------------------------------- Limit (cost=17.74..25.56 rows=5 width=188) (actual time=0.036..0.041 rows=5.00 loops=1) Buffers: shared hit=32 InitPlan 1 -> Seq Scan on query_target (cost=0.00..1.01 rows=1 width=1544) (actual time=0.003..0.003 rows=1.00 loops=1) Buffers: shared hit=1 -> Index Scan using items_ivfflat_idx on items (cost=16.73..4710.00 rows=3000 width=188) (actual time=0.035..0.040 rows=5.00 loops=1) Order By: (embedding <=> (InitPlan 1).col1) Index Searches: 1 Buffers: shared hit=32 Planning: Buffers: shared hit=1 Planning Time: 0.032 ms Execution Time: 0.051 ms (13 rows) probes = 1のときは、100個に分けたグループのうち一番近い1グループだけを見に行くので、読み込んだバッファ数が751 → 32に激減し、実行時間も2.273 ms → 0.051 msと40倍速くなりました。 今回はAIにサンプル文をまとめて生成してもらったせいか似た文章が多くて偏りがあり、たまたま上位5件とも同じ一番近いグループに入っていたため、probes = 1でも5件すべて正解と一致していました。データにばらつきがあってグループの境界付近に正解が散らばっている場合は、probes = 1だと別グループの正解を取りこぼすことがあります。 続いてivfflat.probes = 5に増やしてみます。 vector_db=# SET ivfflat.probes = 5; SET vector_db=# SELECT id, category, sentence FROM items ORDER BY embedding <=> (SELECT q_vec FROM query_target) LIMIT 5; id | category | sentence ------+--------------+------------------------------------------------------------------------------------------------------ 141 | データベース | PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 1341 | データベース | 原則として、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 1741 | データベース | 基本方針として、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 2541 | データベース | セキュリティと品質維持のため、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 2941 | データベース | 全社共通のルールとして、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 (5 rows) vector_db=# EXPLAIN (ANALYZE, BUFFERS) SELECT id, category, sentence FROM items ORDER BY embedding <=> (SELECT q_vec FROM query_target) LIMIT 5; QUERY PLAN ------------------------------------------------------------------------------------------------------------------------------------------- Limit (cost=84.64..92.35 rows=5 width=188) (actual time=0.093..0.097 rows=5.00 loops=1) Buffers: shared hit=78 InitPlan 1 -> Seq Scan on query_target (cost=0.00..1.01 rows=1 width=1544) (actual time=0.003..0.003 rows=1.00 loops=1) Buffers: shared hit=1 -> Index Scan using items_ivfflat_idx on items (cost=83.62..4710.00 rows=3000 width=188) (actual time=0.092..0.096 rows=5.00 loops=1) Order By: (embedding <=> (InitPlan 1).col1) Index Searches: 1 Buffers: shared hit=78 Planning: Buffers: shared hit=1 Planning Time: 0.032 ms Execution Time: 0.106 ms (13 rows) probes = 5にすると近い5グループを見に行くようになり、読み込むページ数は32 → 78に増えますが、それでも実行時間は0.106 msと、Seq Scan（2.273 ms・751ページ）の20倍以上速くなっています。 なお、IVFFlatのグループ分けはインデックス作成時に乱数で決める部分があるようで、同じデータでもインデックスを作り直すと読み込むページ数などの結果が一致しない場合があります。私も2回目に動かしたときはshared hit=61になりました。後述するHNSWも同様のようです。 簡単に補足です。 近似最近傍探索（ANN）というのは、距離の計算式自体を大雑把に近似しているわけではなく、調べる対象の範囲（グループやグラフの探索範囲）を絞ることで読み込むページ数と計算回数を減らす仕組みです。そのため、探索範囲に入ったデータについてはコサイン距離の数値自体は厳密計算とまったく同じになり、近いグループの中に上位データが収まっていれば順位も数値も変わらない、ということみたいです。これで前回の疑問になっていた部分は検証できたかと思います。 HNSW インデックス 続いて、一度IVFFlatインデックスを消してから、HNSWインデックスを作成して試してみます。 vector_db=# DROP INDEX items_ivfflat_idx; DROP INDEX vector_db=# CREATE INDEX items_hnsw_idx ON items USING hnsw (embedding vector_cosine_ops) WITH (m = 16, ef_construction = 64); CREATE INDEX vector_db=# SELECT id, category, sentence FROM items ORDER BY embedding <=> (SELECT q_vec FROM query_target) LIMIT 5; id | category | sentence ------+--------------+------------------------------------------------------------------------------------------------------ 141 | データベース | PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 1341 | データベース | 原則として、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 1741 | データベース | 基本方針として、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 2541 | データベース | セキュリティと品質維持のため、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 2941 | データベース | 全社共通のルールとして、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 (5 rows) vector_db=# EXPLAIN (ANALYZE, BUFFERS) SELECT id, category, sentence FROM items ORDER BY embedding <=> (SELECT q_vec FROM query_target) LIMIT 5; QUERY PLAN ----------------------------------------------------------------------------------------------------------------------------------------- Limit (cost=470.69..480.01 rows=5 width=188) (actual time=0.208..0.212 rows=5.00 loops=1) Buffers: shared hit=436 InitPlan 1 -> Seq Scan on query_target (cost=0.00..1.01 rows=1 width=1544) (actual time=0.007..0.007 rows=1.00 loops=1) Buffers: shared hit=1 -> Index Scan using items_hnsw_idx on items (cost=469.68..6064.00 rows=3000 width=188) (actual time=0.207..0.210 rows=5.00 loops=1) Order By: (embedding <=> (InitPlan 1).col1) Index Searches: 1 Buffers: shared hit=436 Planning: Buffers: shared hit=1 Planning Time: 0.069 ms Execution Time: 0.229 ms (13 rows) HNSWは5件とも正解と一致し、実行時間は0.229 msでした。 比較のためにIVFFlatももう一度作って、テーブルと各インデックスのサイズも見比べてみます。 vector_db=# CREATE INDEX items_ivfflat_idx ON items USING ivfflat (embedding vector_cosine_ops) WITH (lists = 100); CREATE INDEX vector_db=# SELECT relname, pg_size_pretty(pg_relation_size(oid)) AS size FROM pg_class WHERE relname IN ('items', 'items_ivfflat_idx', 'items_hnsw_idx'); relname | size -------------------+--------- items | 6000 kB items_hnsw_idx | 6008 kB items_ivfflat_idx | 5264 kB (3 rows) ここまでの実行時間・バッファ読込数・精度・サイズをまとめると以下のようになりました。 | 検索方法 | 実行時間 | 読込ページ数 (shared hit) | 上位5件の一致数 | インデックスサイズ | | :--- | ---: | ---: | :---: | ---: | | インデックスなし (Seq Scan) | 2.273 ms | 751 | 5 / 5（基準） | - | | IVFFlat (probes = 1) | 0.051 ms | 32 | 5 / 5 | 5264 kB | | IVFFlat (probes = 5) | 0.106 ms | 78 | 5 / 5 | 5264 kB | | HNSW（デフォルト） | 0.229 ms | 436 | 5 / 5 | 6008 kB | IVFFlatは探索するグループ数を絞れるのでバッファ読込数も実行時間もかなり小さく抑えられますが、あらかじめデータが入っている状態で作成しないとグループ分けがうまくいかないという注意点があります。一方、HNSWはデータ追加時にもグラフを繋いでくれてデフォルト設定のまま高い精度が出るので扱いやすいかなと思います。その分、グラフのリンク情報を持つのでインデックスサイズはテーブル本体と同じくらいの大きさ（6008 kB）になっています。 3. 距離計算演算子の比較 前回はコサイン距離（<=>）だけを使いましたが、pgvectorでは全部で6種類の距離計算演算子が用意されています。 | 演算子 | 距離の種類 | 対応する型 | 備考 | | :---: | :--- | :--- | :--- | | <=> | コサイン距離（Cosine） | vector, halfvec, sparsevec | ベクトルの向きの違い（0〜2） | | <-> | L2距離 | vector, halfvec, sparsevec | 2点間の直線距離 | | <#> | 負の内積（Inner Product） | vector, halfvec, sparsevec | 内積にマイナスを掛けた値 | | <+> | L1距離 | vector, halfvec, sparsevec | 各次元の差の絶対値の合計 | | <~> | ハミング距離（Hamming） | bit | 異なるビットの個数 | | <%> | ジャッカード距離（Jaccard） | bit | 集合の重なり具合（0〜1） | 文章のベクトル検索（RAGなど）では、文章の長さや単語の出現回数によってベクトルの大きさ（長さ）が変わっても、ベクトルの向き（意味の方向）がどれくらい近いかを測れるコサイン距離を使うのが一般的です。 なお、Postgresのインデックススキャンは ORDER BY 演算子 ASCで使う仕組みになっているため、内積も似ているほど値が小さくなるように符号を反転させた負の内積（<#>）になっているようです。 ここではvector型で使える4つの演算子（<=>, <->, <#>, <+>）について、以下の2点に着目して比べてみます。 - 各演算子の実行時間（psqlの \timing で計測） - コサイン距離で出てきた上位5件と比べて、他の演算子だとどの文章が近いと判定されるか（検索クエリ「PostgreSQLのインデックスを使ってベクトル検索を高速化する方法」に対する近さ） 純粋な距離計算の時間を比べるため、いったんインデックスを削除し、計測をオンにして4つの演算子を順番に実行してみます。 vector_db=# DROP INDEX items_ivfflat_idx, items_hnsw_idx; DROP INDEX vector_db=# \timing Timing is on. vector_db=# SELECT id, round((embedding <=> (SELECT q_vec FROM query_target))::numeric, 6) AS cosine_dist, sentence FROM items ORDER BY embedding <=> (SELECT q_vec FROM query_target) LIMIT 5; id | cosine_dist | sentence ------+-------------+------------------------------------------------------------------------------------------------------ 141 | 0.086783 | PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 1341 | 0.087194 | 原則として、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 1741 | 0.091633 | 基本方針として、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 2541 | 0.097568 | セキュリティと品質維持のため、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 2941 | 0.098207 | 全社共通のルールとして、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 (5 rows) Time: 3.897 ms vector_db=# SELECT id, round((embedding <-> (SELECT q_vec FROM query_target))::numeric, 6) AS l2_dist, sentence FROM items ORDER BY embedding <-> (SELECT q_vec FROM query_target) LIMIT 5; id | l2_dist | sentence ------+----------+------------------------------------------------------------------------------------------------------ 141 | 0.416612 | PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 1341 | 0.417598 | 原則として、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 1741 | 0.428096 | 基本方針として、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 2541 | 0.441743 | セキュリティと品質維持のため、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 2941 | 0.443185 | 全社共通のルールとして、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 (5 rows) Time: 2.706 ms vector_db=# SELECT id, round((embedding <#> (SELECT q_vec FROM query_target))::numeric, 6) AS neg_ip, sentence FROM items ORDER BY embedding <#> (SELECT q_vec FROM query_target) LIMIT 5; id | neg_ip | sentence ------+-----------+------------------------------------------------------------------------------------------------------ 141 | -0.913217 | PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 1341 | -0.912806 | 原則として、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 1741 | -0.908367 | 基本方針として、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 2541 | -0.902432 | セキュリティと品質維持のため、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 2941 | -0.901793 | 全社共通のルールとして、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 (5 rows) Time: 2.695 ms vector_db=# SELECT id, round((embedding <+> (SELECT q_vec FROM query_target))::numeric, 6) AS l1_dist, sentence FROM items ORDER BY embedding <+> (SELECT q_vec FROM query_target) LIMIT 5; id | l1_dist | sentence ------+----------+------------------------------------------------------------------------------------------------ 141 | 6.382686 | PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 1341 | 6.445336 | 原則として、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 1741 | 6.559072 | 基本方針として、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 2941 | 6.849228 | 全社共通のルールとして、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 541 | 6.869993 | 社内ルールとして、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 (5 rows) Time: 3.595 ms 4つの演算子の実行時間と、上位5件の結果をまとめると以下の通りです。 | 演算子 | 実行時間 | 上位5件のID | コサイン距離との比較 | | :---: | ---: | :--- | :--- | | <=>（コサイン距離） | 3.897 ms | 141, 1341, 1741, 2541, 2941 | 基準（クエリ文に意味が一番近い上位5件） | | <->（L2距離） | 2.706 ms | 141, 1341, 1741, 2541, 2941 | 上位5件・順位ともコサイン距離と完全に一致 | | <#>（負の内積） | 2.695 ms | 141, 1341, 1741, 2541, 2941 | 実行時間が最速で、上位5件・順位ともコサイン距離と完全に一致 | | <+>（L1距離） | 3.595 ms | 141, 1341, 1741, 2941, 541 | 1〜3位は同じだが、4位と5位が入れ替わる | ※文章の比較は一般的にコサイン距離で実施することが多いため、コサイン距離を基準にしています 実行時間で見ると、各次元の掛け算と足し算だけで済む負の内積が2.695 msで一番速く、ベクトルの長さで割る計算が入るコサイン距離が3.897 msと一番時間がかかっています。 また、検索結果の順位を見ると、コサイン距離、L2距離、負の内積の3つが1位から5位までまったく同じ結果になりました。 4. 量子化（halfvec / bit）でどのくらいサイズが下がるか 先ほどHNSWインデックスがテーブル本体と同じくらいのサイズになっていましたが、データ量が増えてきたときにメモリやディスクを節約する機能として、halfvec（16-bit浮動小数点）と binary_quantizeが使えます。 文章検索で一般的なコサイン距離をベースに、元のvector(384)からhalfvec(384)・bit(384)にしたときに、サイズ・実行時間・検索結果がどう変わるかを比べてみました（※ bit型は0と1のビット列でコサイン距離が使えないため、bitのみハミング距離 <~> を使います）。 vector_db=# ALTER TABLE items ADD COLUMN embedding_half halfvec(384), ADD COLUMN embedding_bit bit(384); ALTER TABLE vector_db=# UPDATE items SET embedding_half = embedding::halfvec(384), embedding_bit = binary_quantize(embedding)::bit(384); UPDATE 3000 vector_db=# ANALYZE items; ANALYZE vector_db=# CREATE INDEX items_hnsw_vec_idx ON items USING hnsw (embedding vector_cosine_ops); CREATE INDEX vector_db=# CREATE INDEX items_hnsw_half_idx ON items USING hnsw (embedding_half halfvec_cosine_ops); CREATE INDEX vector_db=# CREATE INDEX items_hnsw_bit_idx ON items USING hnsw (embedding_bit bit_hamming_ops); CREATE INDEX まず、1カラムあたりのバイト数と、HNSWインデックスのサイズを見てみます。 vector_db=# SELECT pg_column_size(embedding) AS vec_bytes, pg_column_size(embedding_half) AS half_bytes, pg_column_size(embedding_bit) AS bit_bytes FROM items LIMIT 1; vec_bytes | half_bytes | bit_bytes -----------+------------+----------- 1540 | 776 | 53 (1 row) vector_db=# SELECT relname, pg_size_pretty(pg_relation_size(oid)) AS index_size FROM pg_class WHERE relname IN ('items_hnsw_vec_idx', 'items_hnsw_half_idx', 'items_hnsw_bit_idx'); relname | index_size ---------------------+------------ items_hnsw_vec_idx | 6008 kB items_hnsw_half_idx | 3440 kB items_hnsw_bit_idx | 1032 kB (3 rows) そして、実行時間を計測しながらそれぞれのインデックスを使って上位5件を検索してみます。 vector_db=# SELECT id, round((embedding <=> (SELECT q_vec FROM query_target))::numeric, 6) AS cosine_dist, sentence FROM items ORDER BY embedding <=> (SELECT q_vec FROM query_target) LIMIT 5; id | cosine_dist | sentence ------+-------------+------------------------------------------------------------------------------------------------------ 141 | 0.086783 | PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 1341 | 0.087194 | 原則として、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 1741 | 0.091633 | 基本方針として、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 2541 | 0.097568 | セキュリティと品質維持のため、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 2941 | 0.098207 | 全社共通のルールとして、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 (5 rows) Time: 0.774 ms vector_db=# SELECT id, round((embedding_half <=> (SELECT q_vec::halfvec(384) FROM query_target))::numeric, 6) AS cosine_dist, sentence FROM items ORDER BY embedding_half <=> (SELECT q_vec::halfvec(384) FROM query_target) LIMIT 5; id | cosine_dist | sentence ------+-------------+------------------------------------------------------------------------------------------------------ 141 | 0.086797 | PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 1341 | 0.087198 | 原則として、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 1741 | 0.091638 | 基本方針として、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 2541 | 0.097574 | セキュリティと品質維持のため、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 2941 | 0.098213 | 全社共通のルールとして、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 (5 rows) Time: 1.045 ms vector_db=# SELECT id, (embedding_bit <~> (SELECT binary_quantize(q_vec)::bit(384) FROM query_target)) AS hamming_dist, sentence FROM items ORDER BY embedding_bit <~> (SELECT binary_quantize(q_vec)::bit(384) FROM query_target) LIMIT 5; id | hamming_dist | sentence ------+--------------+------------------------------------------------------------------------------------------ 1741 | 27 | 基本方針として、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 2141 | 27 | 日常業務において、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 141 | 27 | PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 1341 | 27 | 原則として、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 541 | 28 | 社内ルールとして、PostgreSQLでインデックスを作成すると検索クエリの処理が高速になります。 (5 rows) Time: 0.611 ms 結果をまとめると以下のようになりました。 | データ型（演算子） | 1カラムのサイズ | HNSWインデックスサイズ | 実行時間 | vector（コサイン距離）との結果比較 | | :--- | ---: | ---: | ---: | :--- | | vector (<=>) | 1540 Bytes | 6008 kB | 0.774 ms | 基準（上位5件：141, 1341, 1741, 2541, 2941） | | halfvec (<=>) | 776 Bytes | 3440 kB | 1.045 ms | 上位5件・順位とも完全に一致（距離の小数第5位以下のみ微差） | | bit (<~>) | 53 Bytes | 1032 kB | 0.611 ms | 似た文章が上位に入るが、同率（27）が並び順位が入れ替わる | halfvecにすると、カラムサイズもHNSWインデックスのサイズも約半分（6008 kB → 3440 kB）になり、コサイン距離の値も小数第5位以下がほんの少し変わるだけで、検索結果の上位5件は元のvectorとまったく同じでした。実行時間だけ見るとvector（0.774 ms）よりhalfvec（1.045 ms）の方が少し大きくなっていますが、3,000件くらいだとどちらも1ms前後で終わってしまうので、クエリ内の型キャストや実行タイミングの誤差かなと思います（もっと件数大きくしてやり直したいですが大変なので省略）。精度をほぼ落とさずにメモリ・ディスク使用量を半分近く減らせるので、普段使いならhalfvecはかなり良さそうです。 一方、bit型はサイズが53 Bytes（インデックスも約1/6の1032 kB）、実行時間も0.611 msまで下がり、意味が近い「PostgreSQLでインデックスを作成すると〜」の文章群をちゃんと拾えていますが、1次元を正か負かの1ビットに丸めて整数のハミング距離で比較するため、上位4件がすべて距離27で同率になり細かな順位は入れ替わっていました。 5. WHERE句で絞り込んだときの結果0件問題と Iterative Index Scans 最後に、Iterative Index Scans（反復インデックススキャン）を試してみます。 ベクトル検索をするときに WHERE category = 'セキュリティ規定' のようにカテゴリで絞り込みたいケースはよくあると思いますが、HNSWインデックスを使って絞り込み検索をすると、結果が0件になってしまうことがあります。この挙動は hnsw.iterative_scan の設定で切り替えることができます。デフォルトは offです。 今回は全体の5%（3,000件中150件）が該当するcategory = 'セキュリティ規定'という条件で、hnsw.ef_search = 20にして上位5件を検索してみます。 まず hnsw.iterative_scan = off に設定した場合です。 vector_db=# \timing off Timing is off. vector_db=# SET hnsw.ef_search = 20; SET vector_db=# SET hnsw.iterative_scan = off; SET vector_db=# SELECT id, category, sentence FROM items WHERE category = 'セキュリティ規定' ORDER BY embedding <=> (SELECT q_vec FROM query_target) LIMIT 5; id | category | sentence ----+----------+---------- (0 rows) vector_db=# EXPLAIN (ANALYZE, BUFFERS) SELECT id, category, sentence FROM items WHERE category = 'セキュリティ規定' ORDER BY embedding <=> (SELECT q_vec FROM query_target) LIMIT 5; QUERY PLAN -------------------------------------------------------------------------------------------------------------------------------------------- Limit (cost=289.93..526.84 rows=5 width=188) (actual time=0.277..0.278 rows=0.00 loops=1) Buffers: shared hit=290 InitPlan 1 -> Seq Scan on query_target (cost=0.00..1.01 rows=1 width=1544) (actual time=0.006..0.007 rows=1.00 loops=1) Buffers: shared hit=1 -> Index Scan using items_hnsw_vec_idx on items (cost=288.92..7396.38 rows=150 width=188) (actual time=0.276..0.277 rows=0.00 loops=1) Order By: (embedding <=> (InitPlan 1).col1) Filter: (category = 'セキュリティ規定'::text) Rows Removed by Filter: 20 Index Searches: 1 Buffers: shared hit=290 Planning: Buffers: shared hit=1 Planning Time: 0.077 ms Execution Time: 0.295 ms (15 rows) iterative_scan = offのときは、まずHNSWインデックスでベクトルが近い上位20件（ef_search = 20）だけを取ってきて、その20件に対して Filter: (category = 'セキュリティ規定') をかけています。上位20件がすべてデータベースカテゴリの文などで埋まっており、セキュリティ規定が1件も含まれていなかったため（Rows Removed by Filter: 20）、テーブル全体には150件あるのに (0 rows) になってしまいました。 次に hnsw.iterative_scan = relaxed_order に切り替えて同じSQLを実行してみます。 vector_db=# SET hnsw.iterative_scan = relaxed_order; SET vector_db=# SELECT id, category, sentence FROM items WHERE category = 'セキュリティ規定' ORDER BY embedding <=> (SELECT q_vec FROM query_target) LIMIT 5; id | category | sentence ------+------------------+-------------------------------------------------------------------------------------------------------------------------------------- 345 | セキュリティ規定 | Webアプリケーションを公開する前には脆弱性診断を実施しSQLインジェクションやXSS対策を確認します。 365 | セキュリティ規定 | パスワードマネージャーを利用してサービスごとに異なるランダムな高強度パスワードを生成・管理します。 1945 | セキュリティ規定 | 基本方針として、Webアプリケーションを公開する前には脆弱性診断を実施しSQLインジェクションやXSS対策を確認します。 1545 | セキュリティ規定 | 原則として、Webアプリケーションを公開する前には脆弱性診断を実施しSQLインジェクションやXSS対策を確認します。 2585 | セキュリティ規定 | セキュリティと品質維持のため、ソースコードや設定ファイルを個人のGitHubアカウントや外部のパブリックリポジトリへ公開してはいけません。 (5 rows) vector_db=# EXPLAIN (ANALYZE, BUFFERS) SELECT id, category, sentence FROM items WHERE category = 'セキュリティ規定' ORDER BY embedding <=> (SELECT q_vec FROM query_target) LIMIT 5; QUERY PLAN -------------------------------------------------------------------------------------------------------------------------------------------- Limit (cost=289.93..526.84 rows=5 width=188) (actual time=1.501..2.168 rows=5.00 loops=1) Buffers: shared hit=3237 InitPlan 1 -> Seq Scan on query_target (cost=0.00..1.01 rows=1 width=1544) (actual time=0.007..0.008 rows=1.00 loops=1) Buffers: shared hit=1 -> Index Scan using items_hnsw_vec_idx on items (cost=288.92..7396.38 rows=150 width=188) (actual time=1.500..2.165 rows=5.00 loops=1) Order By: (embedding <=> (InitPlan 1).col1) Filter: (category = 'セキュリティ規定'::text) Rows Removed by Filter: 528 Index Searches: 1 Buffers: shared hit=3237 Planning: Buffers: shared hit=1 Planning Time: 0.113 ms Execution Time: 2.192 ms (15 rows) iterative_scan = relaxed_orderに設定すると、ちゃんとセキュリティ規定の中からSQLインジェクション対策などデータベースに近い文章が5件返ってきました。 EXPLAINの結果を見比べると、裏側で何が起きたかがわかります。offのときはRows Removed by Filter: 20（最初の20件を調べて全部弾かれた時点で終了）だったのに対し、relaxed_orderではRows Removed by Filter: 528、rows=5.00となっており、さらに読み込んだページ数もshared hit=290 → 3237に増えています。つまり、最初の20件で見つからなくても探索を打ち切らず、条件に合うデータが LIMIT 5 件集まるまで（合計533件分）インデックスを自動で掘り進めてくれたことが確認できました。 後片付け 一通り検証が終わったら、作成したテーブルを削除してpsqlから抜けます（テーブルに紐づくインデックスも一緒に削除されます）。 vector_db=# DROP TABLE items, query_target; DROP TABLE vector_db=# \q 補足 用語まとめ 最後に、今回の検証やVector Database周りでよく出てくる用語を日本語と英語でまとめておきます。 | 日本語 | 英語 | 説明 | | :--- | :--- | :--- | | 埋め込み / ベクトル化 | Embedding | テキストや画像などの意味を、数百〜数千個の数値の配列（ベクトル）に変換すること。 | | 次元数 | Dimensions | 1つのベクトルに含まれる数値の個数。今回使ったデータは384次元。 | | 正規化 | Normalization | ベクトルの長さを 1 に揃えること。正規化しておくと内積とコサイン距離の順位が同じになる。 | | 最近傍探索（厳密検索） | Exact Nearest Neighbor (ENN) / k-NN | 全データと距離を計算して正確な上位K件を探す方法。インデックスなしの Seq Scan がこれにあたる。 | | 近似最近傍探索 | Approximate Nearest Neighbor (ANN) | 探索する範囲を絞ることで、多少の取りこぼしを許容する代わりに高速に検索する手法。IVFFlat や HNSW が該当する。 | | 再現率 | Recall | 厳密検索での正解上位K件のうち、近似検索で何割を拾えたかを表す指標。 | | 転置ファイルインデックス | IVFFlat (Inverted File Flat) | データをあらかじめ複数のグループ（lists）に分けておき、検索時は近いグループ（probes 個）だけを調べるインデックス。 | | 階層的ナビゲーション可能スモールワールド | HNSW (Hierarchical Navigable Small World) | データを多層のグラフ構造で繋いで探索するインデックス。事前学習なしで高い精度が出やすい。 | | 量子化 | Quantization | 32-bit浮動小数点（vector）をより少ないビット数で表現して、メモリやディスク使用量を減らす手法。 | | 半精度浮動小数点（スカラー量子化） | Half-Precision Float (halfvec) | 1次元を32-bitから16-bit（2バイト）に減らすデータ型。精度をあまり落とさずにサイズを約半分にできる。 | | バイナリ量子化 | Binary Quantization (binary_quantize) | 1次元を正負の 0 か 1（1ビット）に圧縮する手法。データサイズは約1/32になる。 | | 疎ベクトル / 密ベクトル | Sparse Vector (sparsevec) / Dense Vector | ほとんどの要素に値が入っている通常のベクトルが Dense Vector、単語の出現頻度のように大半の要素が 0 のベクトルが Sparse Vector。 | | 再ランキング | Re-ranking | 軽いインデックス（bit など）で多めに候補を取ってきたあと、元の vector などで距離を計算し直して上位K件に並べ替える手法。 | | 反復インデックススキャン | Iterative Index Scans | WHERE 句で絞り込みをしたときに、LIMIT の件数に達するまでインデックス探索を自動で繰り返す機能。 | | ページ（ブロック） | Page / Block | Postgresがディスクやメモリ（shared_buffers）を読み書きする基本単位（デフォルトは8KB）。 | おわりに 前回の記事で疑問に残っていた「なぜ近似検索なのに結果や距離の数値が変わらなかったのか」というところから、pgvectorの各機能まで一通り実機で動かして確認できました。 実際に日本語の文章データを入れてpsqlでEXPLAIN (ANALYZE, BUFFERS)やインデックスのサイズを見ながら動かすと、裏側で何をやっているのかイメージしやすかったです。特にドキュメントを読んだだけではIterative Index Scansの何がIterative（反復）なのか理解できなかったのですが、実際の動きを見たらわかりやすかったです。 なお、今回の検証で試した機能や設定については基本的にすべてpgvector公式GitHubのREADMEに載っているので、細かいパラメータや仕様が気になった方はそちらもあわせて参照してみてください。 pgvectorはもうすぐ 0.9.0が公開されそうです。楽しみですね！ 以上です。最後まで読んでいただきありがとうございます! 参考 - pgvector (GitHub) - pgvector/pgvector - 前回の記事：pgvectorで学ぶVector Database（RAGの基礎） - qiita.com

@kartikktwt Benchmark pgvector with the filters your app will use. Its approximate indexes apply filtering after the scan, so selective filters can return fewer rows than LIMIT; iterative scans can help. pgvector/pgvector

The Ultimate Developer Stack: 23 Trending GitHub Repos | 28-10-2026 | Dev Repos Daily cutt.ly 🔥 Nobody Told You About This New AI Repo (Summer2027-Internships) Stay on top of the open source ecosystem with this handpicked selection of trending GitHub repositories. From innovative developer tools to groundbreaking frameworks, these are the projects making waves in the software community right now. October 28, 2026 What is inside this video: - Top 23 trending GitHub repositories ranked by stars gained today - Developer insights and project overviews for every featured repo - AI-narrated walkthrough of each open source project - Direct links to all repositories below for easy access ⏱️ TIMESTAMPS (YouTube Chapters): 00:00 - Intro: Today's High-Impact Tools 00:09 - Trending Leaderboard Overview 00:25 - #1 Summer2027-Internships 00:54 - #2 n8n 01:24 - #3 datahub 01:45 - #4 upscayl 02:08 - #5 free-for-dev 02:33 - #6 awesome-remote-job 02:59 - #7 Data-Science-For-Beginners 03:27 - #8 PowerToys 03:50 - #9 neovim 04:10 - #10 jellyfin 04:33 - #11 llama_index 04:56 - #12 syft 05:18 - #13 playwright 05:46 - #14 plane 06:09 - #15 pgvector 06:28 - #16 awesome 06:59 - #17 runner-images 07:19 - #18 rustdesk 07:43 - #19 lazygit 08:05 - #20 transformers 08:31 - #21 directus 09:02 - #22 gitleaks 09:22 - #23 OpenCore-Legacy-Patcher 09:45 - Outro & Key Takeaways ━━━━━━━━━━━━━━━━━━━━━━━ TODAY'S TOP 23 TRENDING REPOSITORIES: ━━━━━━━━━━━━━━━━━━━━━━━ #1 SimplifyJobs/Summer2027-Internships (⭐ 48.2k • +21 today • Python) Summer 2027 software engineering, data science, AI, quant, product management, and hardware internship postings. Updated daily by Simplify and Pitt CSC. 🔗 SimplifyJobs/Summer2027-Internships #2 n8n-io/n8n (⭐ 208.9k • +161 today • TypeScript) Fair-code workflow automation platform with native AI capabilities. Combine visual building with custom code, self-host or cloud, 400+ integrations. 🔗 n8n-io/n8n #3 datahub-project/datahub (⭐ 12.9k • +10 today • Python) The Context Platform for your Data and AI Stack 🔗 datahub-project/datahub #4 upscayl/upscayl (⭐ 51.2k • +76 today • TypeScript) 🆙 Upscayl - #1 Free and Open Source AI Image Upscaler for Linux, MacOS and Windows. 🔗 upscayl/upscayl #5 ripienaar/free-for-dev (⭐ 140.2k • +55 today • HTML) A list of SaaS, PaaS and IaaS offerings that have free tiers of interest to devops and infradev 🔗 ripienaar/free-for-dev #6 lukasz-madon/awesome-remote-job (⭐ 50k • +99 today • Unknown) A curated list of awesome remote jobs and resources. Inspired by vinta/awesome-python 🔗 lukasz-madon/awesome-remote-job #7 microsoft/Data-Science-For-Beginners (⭐ 37.8k • +47 today • Jupyter Notebook) 10 Weeks, 20 Lessons, Data Science for All! 🔗 microsoft/Data-Science-For-Beginners #8 microsoft/PowerToys (⭐ 140.1k • +84 today • C) Microsoft PowerToys is a collection of utilities that supercharge productivity and customization on Windows 🔗 microsoft/PowerToys #9 neovim/neovim (⭐ 103.2k • +41 today • Vim Script) Vim-fork focused on extensibility and usability 🔗 neovim/neovim #10 jellyfin/jellyfin (⭐ 58.7k • +74 today • C#) The Free Software Media System - Server Backend & API 🔗 jellyfin/jellyfin #11 run-llama/llama_index (⭐ 52.7k • +23 today • Python) LlamaIndex is the document processing platform for AI 🔗 run-llama/llama_index #12 anchore/syft (⭐ 9.8k • +14 today • Go) CLI tool and library for generating a Software Bill of Materials from container images and filesystems 🔗 anchore/syft #13 microsoft/playwright (⭐ 98.7k • +90 today • TypeScript) Playwright is a framework for Web Testing and Automation. It allows testing Chromium, Firefox and WebKit with a single API. 🔗 microsoft/playwright #14 makeplane/plane (⭐ 61.6k • +64 today • TypeScript) 🔥🔥🔥 Open-source Jira, Linear, Monday, and ClickUp alternative. Plane is a modern project management platform to manage tasks, sprints, docs, and triage. 🔗 makeplane/plane #15 pgvector/pgvector (⭐ 23.5k • +17 today • C) Open-source vector similarity search for Postgres 🔗 pgvector/pgvector ━━━━━━━━━━━━━━━━━━━━━━━ Subscribe to @devrepos for daily GitHub trending repositories, open source roundups, and developer news. New videos every day covering the best open source software and trending projects on GitHub. [ar] أفضل حزمة أدوات للمطورين: 23 مستودعاً رائجاً على GitHub | 28-10-2026 | مستودعات المطورين اليومية cutt.ly 🔥 لم يخبرك أحد عن هذا المستودع الجديد للذكاء الاصطناعي (تدريب صيفي 2027) ابقَ على اطلاع دائم بأحدث التطورات في عالم البرمجيات مفتوحة المصدر مع هذه المجموعة المختارة بعناية من مستودعات GitHub الرائجة. من أدوات تطوير مبتكرة إلى أطر عمل رائدة، هذه هي المشاريع التي تُحدث ضجة في مجتمع البرمجيات حاليًا. ... ٢٨ أكتوبر ٢٠٢٦ محتوى هذا الفيديو: - أفضل ٢٣ مستودعًا رائجًا على GitHub، مُرتبة حسب عدد النجوم المكتسبة اليوم - رؤى المطورين ونظرة عامة على المشاريع لكل مستودع مميز - شرح صوتي مُعزز بالذكاء الاصطناعي لكل مشروع مفتوح المصدر - روابط مباشرة لجميع المستودعات أدناه لسهولة الوصول ⏱️ الفواصل الزمنية (فصول يوتيوب): ٠٠:٠٠ - مقدمة: أدوات اليوم الأكثر تأثيرًا ٠٠:٠٩ - نظرة عامة على قائمة المتصدرين الرائجة ٠٠:٢٥ - #١ تدريب صيفي ٢٠٢٧ ٠٠:٥٤ - #٢ n8n ٠١:٢٤ - #٣ datahub ٠١:٤٥ - #٤ upscayl ٠٢:٠٨ - #٥ free-for-dev ٠٢:٣٣ - #٦ awesome-remote-job ٠٢:٥٩ - #٧ علوم البيانات للمبتدئين ٠٣:٢٧ - #٨ باور تويز 03:50 - #9 نيوفيم 04:10 - #10 جيلي فين 04:33 - #11 لاما إندكس 04:56 - #12 سيفت 05:18 - #13 بلاي رايت 05:46 - #14 بلين 06:09 - #15 بي جي فيكتور 06:28 - #16 أوسوم 06:59 - #17 رانر إيمجز 07:19 - #18 رست ديسك 07:43 - #19 ليزي جيت 08:05 - #20 ترانسفورمرز 08:31 - #21 دايركت توس 09:02 - #22 جيت ليكس 09:22 - #23 أوبن كور ليجاسي باتشر 09:45 - الخاتمة والمفتاح أهم النقاط ━━━━━━━━━━━━━━━━━━━━━━━━ أفضل 23 موقعًا رائجًا اليوم: ━━━━━━━━━━━━━━━━━━━━━━━ #1 SimplifyJobs/Summer2027-Internships (⭐ 48.2 ألف • +21 اليوم • بايثون) فرص تدريب صيفية لعام 2027 في هندسة البرمجيات، وعلوم البيانات، والذكاء الاصطناعي، والتحليل الكمي، وإدارة المنتجات، والأجهزة. يتم تحديثها يوميًا بواسطة Simplify و Pitt CSC. 🔗 SimplifyJobs/Summer2027-Internships #2 n8n-io/n8n (⭐ 208.9 ألف • +161 اليوم • TypeScript) منصة أتمتة سير العمل البرمجية العادلة مع إمكانيات ذكاء اصطناعي مدمجة. اجمع بين البناء المرئي والبرمجة المخصصة، مع إمكانية الاستضافة الذاتية أو السحابية، وأكثر من 400 تكامل. منصة أتمتة سير العمل البرمجية العادلة مع إمكانيات الذكاء الاصطناعي المدمجة. 🔗 n8n-io/n8n #3 datahub-project/datahub (⭐ 12.9 ألف • +10 اليوم • بايثون) منصة السياق لبياناتك وتقنيات الذكاء الاصطناعي 🔗 datahub-project/datahub #4 upscayl/upscayl (⭐ 51.2 ألف • +76 اليوم • تايب سكريبت) 🆙 Upscayl - برنامج مجاني ومفتوح المصدر لتحسين جودة الصور بتقنية الذكاء الاصطناعي، يعمل على أنظمة لينكس وماك أو إس وويندوز. ... #3 🔗 upscayl/upscayl #5 ripienaar/free-for-dev (⭐ 140.2 ألف • +55 اليوم • HTML) قائمة بعروض SaaS وPaaS وIaaS التي تتضمن مستويات مجانية تهم مطوري DevOps وInfradev 🔗 ripienaar/free-for-dev #6 lukasz-madon/awesome-remote-job (⭐ 50 ألف • +99 اليوم • غير معروف) قائمة منتقاة من أفضل الوظائف والموارد عن بُعد. مستوحى من vinta/awesome-python 🔗 lukasz-madon/awesome-remote-job #7 مايكروسوفت/علوم البيانات للمبتدئين (⭐ 37.8 ألف • +47 اليوم • Jupyter Notebook) 10 أسابيع، 20 درسًا، علوم البيانات للجميع! #7 🔗 microsoft/Data-Science-For-Beginners #8 microsoft/PowerToys (⭐ 140.1 ألف • +84 اليوم • C) مجموعة أدوات Microsoft PowerToys تُعزز الإنتاجية وتُتيح تخصيص نظام Windows. 🔗 microsoft/PowerToys #9 neovim/neovim (⭐ 103.2 ألف • +41 اليوم • سكربت Vim) نسخة مُعدّلة من Vim تُركز على قابلية التوسع وسهولة الاستخدام. 🔗 neovim/neovim #10 jellyfin/jellyfin (⭐ 58.7 ألف • +74 اليوم • C#) نظام الوسائط البرمجية الحرة - خادم خلفي وواجهة برمجة تطبيقات (API) 🔗 jellyfin/jellyfin #11 run-llama/llama_index (⭐ ٥٢٫٧ ألف • +٢٣ اليوم • بايثون) LlamaIndex هي منصة معالجة المستندات للذكاء الاصطناعي 🔗 run-llama/llama_index #١٢ anchore/syft (⭐ ٩٫٨ ألف • +١٤ اليوم • جو) أداة سطر أوامر ومكتبة لإنشاء قائمة مكونات برمجية من صور الحاويات وأنظمة الملفات 🔗 anchore/syft #١٣ microsoft/playwright (⭐ ٩٨٫٧ ألف • +٩٠ اليوم • تايب سكريبت) Playwright هو إطار عمل لاختبار وأتمتة الويب. يتيح اختبار Chromium وFirefox وWebKit باستخدام واجهة برمجة تطبيقات واحدة. #١٣ microsoft/playwright (⭐ ٩٨٫٧ ألف • +٩٠ اليوم • تايب سكريبت) Playwright هو إطار عمل لاختبار وأتمتة الويب. يتيح اختبار Chromium وFirefox وWebKit باستخدام واجهة برمجة تطبيقات واحدة. 🔗 microsoft/playwright #14 makeplane/plane (⭐ 61.6 ألف • +64 اليوم • TypeScript) 🔥🔥🔥 بديل مفتوح المصدر لـ Jira وLinear وMonday وClickUp. Plane منصة حديثة لإدارة المشاريع، تُتيح إدارة المهام، والسباقات، والوثائق، وفرز المهام. Plane 🔗 makeplane/plane #15 pgvector/pgvector (⭐ 23.5 ألف • +17 اليوم • C) بحث مفتوح المصدر عن تشابه المتجهات لـ Postgres 🔗 pgvector/pgvector ━━━━━━━━━━━━━━━━━━━━━━━ اشترك في @devrepos للاطلاع على أحدث مستودعات GitHub الرائجة، وملخصات المشاريع مفتوحة المصدر، وأخبار المطورين. فيديوهات جديدة يوميًا تغطي أفضل برامج المصادر المفتوحة والمشاريع الرائجة على GitHub. [bn] ডেভেলপারদের জন্য সেরা কালেকশন: ২৩টি ট্রেন্ডিং গিটহাব রিপোজিটরি | ২৮-১০-২০২৬ | ডেভ রিপোস ডেইলি cutt.ly 🔥 এই নতুন এআই রিপোটির কথা আপনাকে কেউ বলেনি (সামার ২০২৭-ইন্টার্নশিপ) ট্রেন্ডিং গিটহাব রিপোজিটরিগুলোর এই বিশেষভাবে নির্বাচিত সংগ্রহের মাধ্যমে ওপেন সোর্স ইকোসিস্টেমের সাথে আপ-টু-ডেট থাকুন। উদ্ভাবনী ডেভেলপার টুলস থেকে শুরু করে যুগান্তকারী ফ্রেমওয়ার্ক পর্যন্ত, এই প্রজেক্টগুলোই এখন সফটওয়্যার কমিউনিটিতে আলোড়ন সৃষ্টি করছে। ২৮শে অক্টোবর, ২০২৬ এই ভিডিওতে যা আছে: আজ অর্জিত স্টারের ভিত্তিতে র‍্যাঙ্ক করা শীর্ষ ২৩টি ট্রেন্ডিং গিটহাব রিপোজিটরি - প্রতিটি ফিচার করা রিপোর জন্য ডেভেলপারদের মতামত এবং প্রজেক্টের সংক্ষিপ্ত বিবরণ - প্রতিটি ওপেন সোর্স প্রজেক্টের AI-বর্ণিত ওয়াকথ্রু - সহজে অ্যাক্সেসের জন্য নিচে সমস্ত রিপোজিটরির সরাসরি লিঙ্ক ⏱️ ​​টাইমস্ট্যাম্প (ইউটিউব চ্যাপ্টার): ০০:০০ - ভূমিকা: আজকের হাই-ইমপ্যাক্ট টুলস ০০:০৯ - ট্রেন্ডিং লিডারবোর্ডের সংক্ষিপ্ত বিবরণ ০০:২৫ - #১ Summer2027-Internships ০০:৫৪ - #২ n8n ০১:২৪ - #৩ datahub ০১:৪৫ - #৪ upscayl ০২:০৮ - #৫ free-for-dev ০২:৩৩ - #৬ awesome-remote-job ০২:৫৯ - #৭ Data-Science-For-Beginners ০৩:২৭ - #৮ পাওয়ারটয়েজ ০৩:৫০ - #৯ নিওভিম ০৪:১০ - #১০ জেলিফিন ০৪:৩৩ - #১১ লামা_ইনডেক্স ০৪:৫৬ - #১২ সাইফট ০৫:১৮ - #১৩ প্লেরাইট ০৫:৪৬ - #১৪ প্লেন ০৬:০৯ - #১৫ পিজিভেক্টর ০৬:২৮ - #১৬ অসাম ০৬:৫৯ - #১৭ রানার-ইমেজেস ০৭:১৯ - #১৮ রাস্টডেস্ক ০৭:৪৩ - #১৯ লেজিগিট ০৮:০৫ - #২০ ট্রান্সফর্মার্স ০৮:৩১ - #২১ ডিরেক্টাস ০৯:০২ - #২২ গিটলিকস ০৯:২২ - #২৩ ওপেনকোর-লেগ্যাসি-প্যাচার ০৯:৪৫ - আউটরো ও কী মূল কথা ━━━━━━━━━━━━━━━━━━━━━━━ আজকের শীর্ষ ২৩টি ট্রেন্ডিং রিপোজিটরি: ━━━━━━━━━━━━━━━━━━━━━━ #১ SimplifyJobs/Summer2027-Internships (⭐ ৪৮.২ হাজার • আজ +২১ • পাইথন) সামার ২০২৭ সফটওয়্যার ইঞ্জিনিয়ারিং, ডেটা সায়েন্স, এআই, কোয়ান্ট, প্রোডাক্ট ম্যানেজমেন্ট, এবং হার্ডওয়্যার ইন্টার্নশিপের পোস্ট। Simplify এবং Pitt CSC দ্বারা প্রতিদিন আপডেট করা হয়। 🔗 SimplifyJobs/Summer2027-Internships #২ n8n-io/n8n (⭐ ২০৮.৯ হাজার • আজ +১৬১ • টাইপস্ক্রিপ্ট) নেটিভ এআই সক্ষমতাসহ ফেয়ার-কোড ওয়ার্কফ্লো অটোমেশন প্ল্যাটফর্ম। ভিজ্যুয়াল বিল্ডিংয়ের সাথে কাস্টম কোড, সেলফ-হোস্ট বা ক্লাউড, ৪০০+ ইন্টিগ্রেশন একত্রিত করুন। 🔗 n8n-io/n8n #৩ datahub-project/datahub (⭐ ১২.৯ হাজার • আজ +১০ • পাইথন) আপনার ডেটা এবং এআই স্ট্যাকের জন্য কনটেক্সট প্ল্যাটফর্ম। 🔗 datahub-project/datahub #৪ upscayl/upscayl (⭐ ৫১.২ হাজার • আজ +৭৬ • টাইপস্ক্রিপ্ট) 🆙 Upscayl - লিনাক্স, ম্যাকওএস এবং উইন্ডোজের জন্য #১ ফ্রি এবং ওপেন সোর্স এআই ইমেজ আপস্কেলার। 🔗 upscayl/upscayl #5 ripienaar/free-for-dev (⭐ 140.2k • আজ +55 • HTML) SaaS, PaaS এবং IaaS অফারগুলির একটি তালিকা, যেগুলির ফ্রি টিয়ার রয়েছে এবং যা ডেভঅপ্স ও ইনফ্রাডেভের জন্য আকর্ষণীয়। 🔗 ripienaar/free-for-dev #6 lukasz-madon/awesome-remote-job (⭐ 50k • আজ +99 • অজানা) চমৎকার রিমোট চাকরি এবং রিসোর্সের একটি সংকলিত তালিকা। vinta/awesome-python দ্বারা অনুপ্রাণিত 🔗 lukasz-madon/awesome-remote-job #৭ microsoft/Data-Science-For-Beginners (⭐ ৩৭.৮ হাজার • আজ +৪৭ • জুপিটার নোটবুক) ১০ সপ্তাহ, ২০টি পাঠ, সকলের জন্য ডেটা সায়েন্স! 🔗 microsoft/Data-Science-For-Beginners #৮ microsoft/PowerToys (⭐ ১৪০.১ হাজার • আজ +৮৪ • C) মাইক্রোসফট পাওয়ারটয়েজ হলো ইউটিলিটিগুলোর একটি সংগ্রহ যা উইন্ডোজে উৎপাদনশীলতা এবং কাস্টমাইজেশনকে দারুণভাবে বাড়িয়ে তোলে। 🔗 microsoft/PowerToys #৯ neovim/neovim (⭐ ১০৩.২ হাজার • আজ +৪১ • Vim Script) এক্সটেনসিবিলিটি এবং ব্যবহারযোগ্যতার উপর দৃষ্টি নিবদ্ধ একটি ভিম-ফর্ক। 🔗 neovim/neovim #১০ jellyfin/jellyfin (⭐ ৫৮.৭ হাজার • আজ +৭৪ • C#) ফ্রি সফটওয়্যার মিডিয়া সিস্টেম - সার্ভার ব্যাকএন্ড এবং এপিআই। 🔗 jellyfin/jellyfin #১১ run-llama/llama_index (⭐ ৫২.৭ হাজার • আজ +২৩) • পাইথন) লামা ইনডেক্স (LlamaIndex) হলো এআই (AI)-এর জন্য ডকুমেন্ট প্রসেসিং প্ল্যাটফর্ম 🔗 run-llama/llama_index #১২ অ্যাঙ্কোর/সিফট (⭐ ৯.৮ হাজার • আজ +১৪ • গো) কন্টেইনার ইমেজ এবং ফাইলসিস্টেম থেকে সফটওয়্যার বিল অফ মেটেরিয়ালস (Software Bill of Materials) তৈরি করার জন্য একটি সিএলআই (CLI) টুল এবং লাইব্রেরি 🔗 anchore/syft #১৩ মাইক্রোসফট/প্লেরাইট (⭐ ৯৮.৭ হাজার • আজ +৯০ • টাইপস্ক্রিপ্ট) প্লেরাইট (Playwright) হলো ওয়েব টেস্টিং এবং অটোমেশনের জন্য একটি ফ্রেমওয়ার্ক। এটি একটিমাত্র এপিআই (API) দিয়ে ক্রোমিয়াম (Chromium), ফায়ারফক্স (Firefox) এবং ওয়েবকিট (WebKit) পরীক্ষা করার সুযোগ দেয়। 🔗 microsoft/playwright #১৪ মেকপ্লেন/প্লেন (⭐ ৬১.৬ হাজার • আজ +৬৪ • টাইপস্ক্রিপ্ট) 🔥🔥🔥 ওপেন-সোর্স জিরা (Jira), লিনিয়ার (Linear), মানডে (Monday), এবং ক্লিকআপ (ClickUp)-এর বিকল্প। প্লেন হলো টাস্ক, স্প্রিন্ট, ডক্স এবং ট্রায়েজ পরিচালনার জন্য একটি আধুনিক প্রজেক্ট ম্যানেজমেন্ট প্ল্যাটফর্ম। 🔗 makeplane/plane #15 pgvector/pgvector (⭐ ২৩.৫ হাজার • আজ +১৭ • C) পোস্টগ্রেসের জন্য ওপেন-সোর্স ভেক্টর সিমিলারিটি সার্চ 🔗 pgvector/pgvector ━━━━━━━━━━━━━━━━━━━━━━ প্রতিদিনের গিটহাব ট্রেন্ডিং রিপোজিটরি, ওপেন সোর্স রাউন্ডআপ এবং ডেভেলপার নিউজের জন্য @devrepos-এ সাবস্ক্রাইব করুন। প্রতিদিন গিটহাবের সেরা ওপেন সোর্স সফটওয়্যার এবং ট্রেন্ডিং প্রজেক্টগুলো নিয়ে নতুন ভিডিও আসে। [de-DE] Der ultimative Entwickler-Stack: 23 angesagte GitHub-Repos | 28.10.2026 | Dev Repos Daily cutt.ly 🔥 Dieses neue KI-Repository ist noch ein Geheimtipp (Sommer 2027 – Praktika) Bleiben Sie mit dieser handverlesenen Auswahl angesagter GitHub-Repositories immer auf dem Laufenden im Open-Source-Ökosystem. Von innovativen Entwicklertools bis hin zu bahnbrechenden Frameworks – diese Projekte begeistern die Software-Community geradezu. 28. Oktober 2026 Inhalt dieses Videos: - Die 23 beliebtesten GitHub-Repositories, sortiert nach den heute erhaltenen Sternen - Entwickler-Einblicke und Projektübersichten zu jedem vorgestellten Repository - KI-gestützter Rundgang durch jedes Open-Source-Projekt - Direkte Links zu allen Repositories für einfachen Zugriff ⏱️ ZEITSTEMPEL (YouTube-Kapitel): 00:00 - Intro: Die wichtigsten Tools von heute 00:09 - Übersicht der beliebtesten Repositories 00:25 - #1 Sommer 2027 – Praktika 00:54 - #2 n8n 01:24 - #3 datahub 01:45 - #4 upscayl 02:08 - #5 free-for-dev 02:33 - #6 awesome-remote-job 02:59 - #7 Data-Science-For-Beginners 03:27 - #8 PowerToys 03:50 – #9 neovim 04:10 – #10 jellyfin 04:33 – #11 llama_index 04:56 – #12 syft 05:18 – #13 playwright 05:46 – #14 plane 06:09 – #15 pgvector 06:28 – #16 awesome 06:59 – #17 runner-images 07:19 – #18 rustdesk 07:43 – #19 lazygit 08:05 – #20 transformers 08:31 – #21 directus 09:02 – #22 gitleaks 09:22 – #23 OpenCore-Legacy-Patcher 09:45 – Abspann & Legende Wichtigste Erkenntnisse ━━━━━━━━━━━━━━━━━━━━━━━ Die 23 beliebtesten Jobportale von heute: ━━━━━━━━━━━━━━━━━━━━━━━ #1 SimplifyJobs/Sommer 2027 – Praktika (⭐ 48,2k • +21 heute • Python) Stellenangebote für Praktika im Bereich Softwareentwicklung, Data Science, KI, Quantitative Methoden, Produktmanagement und Hardware im Sommer 2027. Täglich aktualisiert von Simplify und Pitt CSC. 🔗 SimplifyJobs/Summer2027-Internships #2 n8n-io/n8n (⭐ 208,9k • +161 heute • TypeScript) Fair-Code-Workflow-Automatisierungsplattform mit nativen KI-Funktionen. Visuelles Erstellen mit benutzerdefiniertem Code kombinieren, selbst hosten oder in der Cloud, über 400 Integrationen. 🔗 n8n-io/n8n #3 datahub-project/datahub (⭐ 12,9k • +10 heute • Python) Die Kontextplattform für Ihren Daten- und KI-Stack. 🔗 datahub-project/datahub #4 upscayl/upscayl (⭐ 51,2k • +76 heute • TypeScript) 🆙 Upscayl – Nr. 1 kostenloser Open-Source-KI-Bild-Upscaler für Linux, macOS und Windows. 🔗 upscayl/upscayl #5 ripienaar/free-for-dev (⭐ 140.200 • +55 heute • HTML) Eine Liste von SaaS-, PaaS- und IaaS-Angeboten mit kostenlosen Tarifen, die für DevOps- und Infrastrukturentwickler interessant sind. 🔗 ripienaar/free-for-dev #6 lukasz-madon/awesome-remote-job (⭐ 50.000 • +99 heute • Unbekannt) Eine kuratierte Liste mit tollen Remote-Jobs und Ressourcen. Inspiriert von vinta/awesome-python 🔗 lukasz-madon/awesome-remote-job #7 microsoft/Data-Science-For-Beginners (⭐ 37,8k • +47 heute • Jupyter Notebook) 10 Wochen, 20 Lektionen: Data Science für alle! 🔗 microsoft/Data-Science-For-Beginners #8 microsoft/PowerToys (⭐ 140,1k • +84 heute • C) Microsoft PowerToys ist eine Sammlung von Hilfsprogrammen, die die Produktivität und Anpassungsmöglichkeiten unter Windows deutlich verbessern. 🔗 microsoft/PowerToys #9 neovim/neovim (⭐ 103,2k • +41 heute • Vim Script) Vim-Fork mit Fokus auf Erweiterbarkeit und Benutzerfreundlichkeit. 🔗 neovim/neovim #10 jellyfin/jellyfin (⭐ 58,7k • +74 heute • C#) Das Free Software Media System – Server-Backend & API 🔗 jellyfin/jellyfin #11 run-llama/llama_index (⭐ 52,7k • +23 heute • Python) LlamaIndex ist die Dokumentenverarbeitungsplattform für KI. 🔗 run-llama/llama_index #12 anchore/syft (⭐ 9,8k • +14 heute • Go) CLI-Tool und Bibliothek zur Generierung einer Software-Stückliste aus Container-Images und Dateisystemen. 🔗 anchore/syft #13 microsoft/playwright (⭐ 98,7k • +90 heute • TypeScript) Playwright ist ein Framework für Webtests und -automatisierung. Es ermöglicht das Testen von Chromium, Firefox und WebKit mit einer einzigen API. 🔗 microsoft/playwright #14 makeplane/plane (⭐ 61,6k • +64 heute • TypeScript) 🔥🔥🔥 Plane ist eine Open-Source-Alternative zu Jira, Linear, Monday und ClickUp. Es handelt sich um eine moderne Projektmanagement-Plattform zur Verwaltung von Aufgaben, Sprints, Dokumenten und Priorisierung. 🔗 makeplane/plane #15 pgvector/pgvector (⭐ 23,5k • +17 heute • C) Open-Source-Vektorähnlichkeitssuche für PostgreSQL 🔗 pgvector/pgvector ━━━━━━━━━━━━━━━━━━━━━━━━ Abonniere @devrepos für täglich aktuelle GitHub-Repositories, Open-Source-Übersichten und Entwickler-News. Täglich neue Videos zu den besten Open-Source-Softwareprojekten und Trendprojekten auf GitHub. [es-US] El stack definitivo para desarrolladores: 23 repositorios de GitHub en tendencia | 28/10/2026 | D... cutt.ly 🔥 Nadie te habló de este nuevo repositorio de IA (Prácticas de verano de 2027) Mantente al día con el ecosistema de código abierto con esta selección de repositorios de GitHub que marcan tendencia. Desde herramientas innovadoras para desarrolladores hasta frameworks revolucionarios, estos son los proyectos que están causando sensación en la comunidad de software. 28 de octubre de 2026 Contenido de este video: - Los 23 repositorios de GitHub más populares, clasificados según las estrellas obtenidas hoy. - Información para desarrolladores y descripciones generales de cada repositorio destacado. - Tutorial guiado por IA de cada proyecto de código abierto. - Enlaces directos a todos los repositorios a continuación para un acceso fácil. ⏱️ MARCAS DE TIEMPO (Capítulos de YouTube): 00:00 - Introducción: Herramientas de alto impacto de hoy 00:09 - Resumen de la clasificación de tendencias 00:25 - N.° 1: Prácticas de verano de 2027 00:54 - N.° 2: n8n 01:24 - N.° 3: datahub 01:45 - N.° 4: upscayl 02:08 - N.° 5: free-for-dev 02:33 - N.° 6: awesome-remote-job 02:59 - N.° 7: Ciencia de datos para principiantes 03:27 - N.° 8 PowerToys 03:50 - #9 neovim 04:10 - #10 jellyfin 04:33 - #11 llama_index 04:56 - #12 syft 05:18 - #13 playwright 05:46 - #14 plane 06:09 - #15 pgvector 06:28 - #16 awesome 06:59 - #17 runner-images 07:19 - #18 rustdesk 07:43 - #19 lazygit 08:05 - #20 transformers 08:31 - #21 directus 09:02 - #22 gitleaks 09:22 - #23 OpenCore-Legacy-Patcher 09:45 - Outro y clave Conclusiones ━━━━━━━━━━━━━━━━━━━━━━━ LOS 23 REPOSITORIOS MÁS POPULARES DE HOY: ━━━━━━━━━━━━━━━━━━━━━━━━ #1 SimplifyJobs/Summer2027-Interships (⭐ 48.2k • +21 hoy • Python) Ofertas de prácticas de verano de 2027 en ingeniería de software, ciencia de datos, IA, análisis cuantitativo, gestión de productos y hardware. Actualizado diariamente por Simplify y Pitt CSC. 🔗 SimplifyJobs/Summer2027-Internships #2 n8n-io/n8n (⭐ 208.9k • +161 hoy • TypeScript) Plataforma de automatización de flujos de trabajo con código justo y capacidades de IA nativas. Combina la creación visual con código personalizado, autoalojamiento o en la nube, más de 400 integraciones. 🔗 n8n-io/n8n #3 datahub-project/datahub (⭐ 12.9k • +10 hoy • Python) La plataforma de contexto para tu pila de datos e IA. 🔗 datahub-project/datahub #4 upscayl/upscayl (⭐ 51.2k • +76 hoy • TypeScript) 🆙 Upscayl: el escalador de imágenes con IA gratuito y de código abierto n.° 1 para Linux, macOS y Windows. 🔗 upscayl/upscayl #5 ripienaar/free-for-dev (⭐ 140.2k • +55 hoy • HTML) Una lista de ofertas de SaaS, PaaS e IaaS con planes gratuitos de interés para devops e infradev. 🔗 ripienaar/free-for-dev #6 lukasz-madon/awesome-remote-job (⭐ 50k • +99 hoy • Desconocido) Una lista seleccionada de excelentes trabajos y recursos remotos. Inspirado en vinta/awesome-python 🔗 lukasz-madon/awesome-remote-job #7 microsoft/Ciencia de Datos para Principiantes (⭐ 37.8k • +47 hoy • Jupyter Notebook) 10 semanas, 20 lecciones: ¡Ciencia de Datos para todos! 🔗 microsoft/Data-Science-For-Beginners #8 microsoft/PowerToys (⭐ 140.1k • +84 hoy • C) Microsoft PowerToys es una colección de utilidades que potencian la productividad y la personalización en Windows. 🔗 microsoft/PowerToys #9 neovim/neovim (⭐ 103.2k • +41 hoy • Vim Script) Bifurcación de Vim centrada en la extensibilidad y la usabilidad. 🔗 neovim/neovim #10 jellyfin/jellyfin (⭐ 58.7k • +74 hoy • C#) Sistema de medios de software libre: backend y API del servidor. 🔗 jellyfin/jellyfin #11 run-llama/llama_index (⭐ 52.7k • +23 hoy • Python) LlamaIndex es la plataforma de procesamiento de documentos para IA. 🔗 run-llama/llama_index #12 anchore/syft (⭐ 9.8k • +14 hoy • Go) Herramienta y biblioteca de línea de comandos para generar una lista de materiales de software a partir de imágenes de contenedores y sistemas de archivos. 🔗 anchore/syft #13 microsoft/playwright (⭐ 98.7k • +90 hoy • TypeScript) Playwright es un framework para pruebas y automatización web. Permite probar Chromium, Firefox y WebKit con una única API. 🔗 microsoft/playwright #14 makeplane/plane (⭐ 61.6k • +64 hoy • TypeScript) 🔥🔥🔥 Alternativa de código abierto a Jira, Linear, Monday y ClickUp. Plane es una plataforma moderna de gestión de proyectos para administrar tareas, sprints, documentación y priorización de tareas. 🔗 makeplane/plane #15 pgvector/pgvector (⭐ 23.5k • +17 hoy • C) Búsqueda de similitud vectorial de código abierto para PostgreSQL 🔗 pgvector/pgvector ━━━━━━━━━━━━━━━━━━━━━━━━ Suscríbete a @devrepos para ver diariamente los repositorios más populares de GitHub, resúmenes de código abierto y noticias para desarrolladores. Nuevos videos cada d... [fr-FR] Le stack ultime du développeur : 23 dépôts GitHub en vogue | 28/10/2026 | Dev Repos Daily cutt.ly 🔥 Personne ne vous a parlé de ce nouveau dépôt d'IA (Stages été 2027) Restez à la pointe de l'écosystème open source grâce à cette sélection exclusive de dépôts GitHub incontournables. Des outils de développement innovants aux frameworks révolutionnaires, découvrez les projets qui font sensation dans la communauté du logiciel en ce moment. 28 octobre 2026 Contenu de cette vidéo : - Les 23 dépôts GitHub les plus populaires, classés par nombre d'étoiles gagnées aujourd'hui - Présentations et analyses de chaque dépôt mis en avant - Visite guidée commentée par une IA de chaque projet open source - Liens directs vers tous les dépôts ci-dessous pour un accès facile ⏱️ HORODATAGE (Chapitres YouTube) : 00:00 - Introduction : Les outils à fort impact du jour 00:09 - Aperçu du classement des tendances 00:25 - N° 1 Summer2027-Internships 00:54 - N° 2 n8n 01:24 - N° 3 datahub 01:45 - N° 4 upscayl 02:08 - N° 5 free-for-dev 02:33 - N° 6 awesome-remote-job 02:59 - N° 7 Data-Science-For-Beginners 03:27 - N° 8 PowerToys 03:50 - #9 neovim 04:10 - #10 jellyfin 04:33 - #11 llama_index 04:56 - #12 syft 05:18 - #13 playwright 05:46 - #14 plane 06:09 - #15 pgvector 06:28 - #16 awesome 06:59 - #17 runner-images 07:19 - #18 rustdesk 07:43 - #19 lazygit 08:05 - #20 transformers 08:31 - #21 directus 09:02 - #22 gitleaks 09:22 - #23 OpenCore-Legacy-Patcher 09:45 - Conclusion et légende Points clés ━━━━━━━━━━━━━━━━━━━━━━ TOP 23 DES DÉPÔTS LES PLUS CONSULTÉS AUJOURD'HUI : ━━━━━━━━━━━━━━━━━━━━━━━ N° 1 SimplifyJobs/Stages Été 2027 (⭐ 48,2 k • +21 aujourd'hui • Python) Offres de stage Été 2027 en génie logiciel, science des données, IA, analyse quantitative, gestion de produits et matériel informatique. Mise à jour quotidienne par Simplify et Pitt CSC. 🔗 SimplifyJobs/Summer2027-Internships #2 n8n-io/n8n (⭐ 208,9 k • +161 aujourd'hui • TypeScript) Plateforme d'automatisation des flux de travail FairCode avec des fonctionnalités d'IA natives. Combinez la création visuelle avec du code personnalisé, auto-hébergé ou cloud, plus de 400 intégrations. 🔗 n8n-io/n8n #3 datahub-project/datahub (⭐ 12,9 k • +10 aujourd'hui • Python) La plateforme Context pour votre stack de données et d'IA 🔗 datahub-project/datahub #4 upscayl/upscayl (⭐ 51,2 k • +76 aujourd'hui • TypeScript) 🆙 Upscayl - Upscaler d'images IA gratuit et open source n° 1 pour Linux, macOS et Windows. 🔗 upscayl/upscayl #5 ripienaar/free-for-dev (⭐ 140,2 k • +55 aujourd'hui • HTML) Liste d'offres SaaS, PaaS et IaaS proposant des versions gratuites intéressantes pour les développeurs DevOps et Infrastructure. 🔗 ripienaar/free-for-dev #6 lukasz-madon/awesome-remote-job (⭐ 50 k • +99 aujourd'hui • Inconnu) Sélection d'offres d'emploi et de ressources intéressantes pour le télétravail. Inspiré par vinta/awesome-python 🔗 lukasz-madon/awesome-remote-job #7 microsoft/Data-Science-For-Beginners (⭐ 37,8 k • +47 aujourd'hui • Jupyter Notebook) 10 semaines, 20 leçons : la science des données pour tous ! 🔗 microsoft/Data-Science-For-Beginners #8 microsoft/PowerToys (⭐ 140,1 k • +84 aujourd'hui • C) Microsoft PowerToys est une collection d'utilitaires qui optimisent la productivité et la personnalisation sous Windows. 🔗 microsoft/PowerToys #9 neovim/neovim (⭐ 103,2 k • +41 aujourd'hui • Script Vim) Une version dérivée de Vim axée sur l'extensibilité et la facilité d'utilisation. 🔗 neovim/neovim #10 jellyfin/jellyfin (⭐ 58,7 k • +74 aujourd'hui • C#) Le système de gestion de médias de logiciels libres : serveur et API. 🔗 jellyfin/jellyfin #11 run-llama/llama_index (⭐ 52,7 k • +23 aujourd'hui • Python) LlamaIndex est une plateforme de traitement de documents pour l'IA. 🔗 run-llama/llama_index #12 anchore/syft (⭐ 9,8 k • +14 aujourd'hui • Go) Outil et bibliothèque en ligne de commande pour générer une nomenclature logicielle à partir d'images de conteneurs et de systèmes de fichiers. 🔗 anchore/syft #13 microsoft/playwright (⭐ 98,7 k • +90 aujourd'hui • TypeScript) Playwright est un framework pour les tests et l'automatisation web. Il permet de tester Chromium, Firefox et WebKit avec une API unique. 🔗 microsoft/playwright #14 makeplane/plane (⭐ 61,6 k • +64 aujourd'hui • TypeScript) 🔥🔥🔥 Alternative open source à Jira, Linear, Monday et ClickUp. Plane est une plateforme moderne de gestion de projet permettant de gérer les tâches, les sprints, la documentation et le triage. 🔗 makeplane/plane #15 pgvector/pgvector (⭐ 23,5 k • +17 aujourd'hui • C) Outil open source de recherche de similarité vectorielle pour Postgres 🔗 pgvector/pgvector ━━━━━━━━━━━━━━━━━━━━━━ Abonnez-vous à @devrepos pour découvrir chaque jour les dépôts GitHub les plus ... [hi] बेहतरीन डेवलपर स्टैक: 23 ट्रेंडिंग GitHub रिपोज़ | 28-10-2026 | डेव रिपोज़ डेली cutt.ly 🔥 इस नए AI रिपॉजिटरी के बारे में आपको किसी ने नहीं बताया (ग्रीष्म 2027 - इंटर्नशिप) ओपन सोर्स इकोसिस्टम की नवीनतम जानकारी के लिए GitHub के इन चुनिंदा रिपॉजिटरी का इस्तेमाल करें। इनोवेटिव डेवलपर टूल्स से लेकर क्रांतिकारी फ्रेमवर्क तक, ये वो प्रोजेक्ट हैं जो सॉफ्टवेयर जगत में धूम मचा रहे हैं। 28 अक्टूबर, 2026 इस वीडियो में क्या है: - आज प्राप्त स्टार रेटिंग के आधार पर शीर्ष 23 ट्रेंडिंग GitHub रिपॉजिटरी - प्रत्येक प्रदर्शित रिपॉजिटरी के लिए डेवलपर अंतर्दृष्टि और प्रोजेक्ट अवलोकन - प्रत्येक ओपन सोर्स प्रोजेक्ट का AI-नैरेटेड वॉकथ्रू - आसान पहुँच के लिए नीचे सभी रिपॉजिटरी के सीधे लिंक ⏱️ टाइमस्टैम्प (YouTube अध्याय): 00:00 - परिचय: आज के उच्च-प्रभाव वाले उपकरण 00:09 - ट्रेंडिंग लीडरबोर्ड अवलोकन 00:25 - #1 समर 2027 इंटर्नशिप 00:54 - #2 n8n 01:24 - #3 datahub 01:45 - #4 upscayl 02:08 - #5 फ्री-फॉर-डेव 02:33 - #6 शानदार रिमोट जॉब 02:59 - #7 डेटा साइंस फॉर बिगिनर्स 03:27 - #8 पॉवर टॉयज़ 03:50 - #9 नेओविम 04:10 - #10 जेलीफिन 04:33 - #11 लामा_इंडेक्स 04:56 - #12 सिफ्ट 05:18 - #13 प्लेराइट 05:46 - #14 प्लेन 06:09 - #15 पीजीवेक्टर 06:28 - #16 ऑसम 06:59 - #17 रनर-इमेजेज 07:19 - #18 रस्टडेस्क 07:43 - #19 लेज़ीगिट 08:05 - #20 ट्रांसफॉर्मर्स 08:31 - #21 डायरेक्टस 09:02 - #22 गिटलीक्स 09:22 - #23 ओपनकोर-लेगेसी-पैचर 09:45 - आउट्रो और कुंजी मुख्य बिंदु ━━━━━━━━━━━━━━━━━━━━━━━━ आज के शीर्ष 23 ट्रेंडिंग रिपॉजिटरी: ━━━━━━━━━━━━━━━━━━━━━━━━ #1 SimplifyJobs/Summer2027-इंटर्नशिप (⭐ 48.2k • आज +21 • पायथन) ग्रीष्मकालीन 2027 के लिए सॉफ्टवेयर इंजीनियरिंग, डेटा साइंस, एआई, क्वांट, प्रोडक्ट मैनेजमेंट और हार्डवेयर इंटर्नशिप के अवसर। Simplify और Pitt CSC द्वारा प्रतिदिन अपडेट किया जाता है। 🔗 SimplifyJobs/Summer2027-Internships #2 n8n-io/n8n (⭐ 208.9k • आज +161 • TypeScript) नेटिव AI क्षमताओं वाला फेयर-कोड वर्कफ़्लो ऑटोमेशन प्लेटफ़ॉर्म। विज़ुअल बिल्डिंग को कस्टम कोड के साथ मिलाएं, सेल्फ-होस्ट या क्लाउड का उपयोग करें, 400+ इंटीग्रेशन उपलब्ध हैं। 🔗 n8n-io/n8n #3 datahub-project/datahub (⭐ 12.9k • आज +10 • Python) आपके डेटा और AI स्टैक के लिए कॉन्टेक्स्ट प्लेटफ़ॉर्म 🔗 datahub-project/datahub #4 upscayl/upscayl (⭐ 51.2k • आज +76 • TypeScript) 🆙 Upscayl - Linux, MacOS और Windows के लिए नंबर 1 मुफ़्त और ओपन सोर्स AI इमेज अपस्केलर। 🔗 upscayl/upscayl #5 ripienaar/free-for-dev (⭐ 140.2k • आज +55 • HTML) SaaS, PaaS और IaaS सेवाओं की एक सूची जिनमें DevOps और InfraDevelop के लिए उपयोगी निःशुल्क विकल्प उपलब्ध हैं। 🔗 ripienaar/free-for-dev #6 lukasz-madon/awesome-remote-job (⭐ 50k • आज +99 • अज्ञात) शानदार रिमोट जॉब्स और संसाधनों की एक चुनिंदा सूची। vinta/awesome-python से प्रेरित 🔗 lukasz-madon/awesome-remote-job #7 microsoft/Data-Science-For-Beginners (⭐ 37.8k • आज +47 • Jupyter Notebook) 10 सप्ताह, 20 पाठ, सभी के लिए डेटा साइंस! 🔗 microsoft/Data-Science-For-Beginners #8 microsoft/PowerToys (⭐ 140.1k • आज +84 • C) Microsoft PowerToys यूटिलिटीज़ का एक संग्रह है जो Windows पर उत्पादकता और अनुकूलन को बढ़ाता है। 🔗 microsoft/PowerToys #9 neovim/neovim (⭐ 103.2k • आज +41 • Vim Script) विस्तारशीलता और उपयोगिता पर केंद्रित Vim-फोर्क 🔗 neovim/neovim #10 jellyfin/jellyfin (⭐ 58.7k • आज +74 • C#) फ्री सॉफ्टवेयर मीडिया सिस्टम - सर्वर बैकएंड और API 🔗 jellyfin/jellyfin #11 run-llama/llama_index (⭐ 52.7k • आज +23 • Python) LlamaIndex एक AI-आधारित दस्तावेज़ प्रसंस्करण प्लेटफ़ॉर्म है। 🔗 run-llama/llama_index #12 anchore/syft (⭐ 9.8k • आज +14 • Go) कंटेनर इमेज और फ़ाइल सिस्टम से सॉफ़्टवेयर बिल ऑफ़ मैटेरियल्स जनरेट करने के लिए एक CLI टूल और लाइब्रेरी। 🔗 anchore/syft #13 microsoft/playwright (⭐ 98.7k • आज +90 • TypeScript) Playwright वेब टेस्टिंग और ऑटोमेशन के लिए एक फ़्रेमवर्क है। यह एक ही API के साथ Chromium, Firefox और WebKit की टेस्टिंग की सुविधा देता है। 🔗 microsoft/playwright #14 makeplane/plane (⭐ 61.6k • आज +64 • TypeScript) 🔥🔥🔥 ओपन-सोर्स Jira, Linear, Monday और ClickUp का विकल्प। Plane एक आधुनिक प्रोजेक्ट मैनेजमेंट प्लेटफॉर्म है जिसका उपयोग टास्क, स्प्रिंट, डॉक्स और ट्राइएज को मैनेज करने के लिए किया जाता है। 🔗 makeplane/plane #15 pgvector/pgvector (⭐ 23.5k • आज +17 • C) पोस्टग्रेस के लिए ओपन-सोर्स वेक्टर समानता खोज 🔗 pgvector/pgvector ━━━━━━━━━━━━━━━━━━━━━━━━ दैनिक GitHub ट्रेंडिंग रिपॉजिटरी, ओपन सोर्स राउंडअप और डेवलपर समाचारों के लिए @devrepos को सब्सक्राइब करें। GitHub पर सर्वश्रेष्ठ ओपन सोर्स सॉफ़्टवेयर और ट्रेंडिंग प्रोजेक्ट्स को कवर करने वाले नए वीडियो हर दिन देखें। [id] Tumpukan Perangkat Lunak Pengembang Terbaik: 23 Repositori GitHub Terpopuler | 28-10-2026 | Dev R... cutt.ly 🔥 Belum Ada yang Memberitahu Anda Tentang Repositori AI Baru Ini (Magang Musim Panas 2027) Tetap terhubung dengan ekosistem open source dengan pilihan repositori GitHub yang sedang tren ini. Dari alat pengembang yang inovatif hingga kerangka kerja yang inovatif, ini adalah proyek-proyek yang sedang membuat gebrakan di komunitas perangkat lunak saat ini. 28 Oktober 2026 Isi video ini: - 23 repositori GitHub terpopuler yang diurutkan berdasarkan bintang yang diperoleh hari ini - Wawasan pengembang dan ikhtisar proyek untuk setiap repositori unggulan - Panduan yang dinarasikan AI untuk setiap proyek sumber terbuka - Tautan langsung ke semua repositori di bawah ini untuk akses mudah ⏱️ CAP WAKTU (Bab YouTube): 00:00 - Pendahuluan: Alat-alat Berdampak Tinggi Hari Ini 00:09 - Ikhtisar Papan Peringkat Terpopuler 00:25 - #1 Magang Musim Panas 2027 00:54 - #2 n8n 01:24 - #3 datahub 01:45 - #4 upscayl 02:08 - #5 free-for-dev 02:33 - #6 awesome-remote-job 02:59 - #7 Ilmu Data untuk Pemula 03:27 - #8 PowerToys 03:50 - #9 neovim 04:10 - #10 jellyfin 04:33 - #11 llama_index 04:56 - #12 syft 05:18 - #13 playwright 05:46 - #14 plane 06:09 - #15 pgvector 06:28 - #16 awesome 06:59 - #17 runner-images 07:19 - #18 rustdesk 07:43 - #19 lazygit 08:05 - #20 transformers 08:31 - #21 directus 09:02 - #22 gitleaks 09:22 - #23 OpenCore-Legacy-Patcher 09:45 - Outro & Key Poin Penting ━━━━━━━━━━━━━━━━━━━━━━━ 23 REPOSITORI YANG SEDANG TREN HARI INI: ━━━━━━━━━━━━━━━━━━━━━━━ #1 SimplifyJobs/Summer2027-Internships (⭐ 48,2 ribu • +21 hari ini • Python) Lowongan magang musim panas 2027 di bidang rekayasa perangkat lunak, ilmu data, AI, kuantitatif, manajemen produk, dan perangkat keras. Diperbarui setiap hari oleh Simplify dan Pitt CSC. 🔗 SimplifyJobs/Summer2027-Internships #2 n8n-io/n8n (⭐ 208,9 ribu • +161 hari ini • TypeScript) Platform otomatisasi alur kerja fair-code dengan kemampuan AI asli. Gabungkan pembuatan visual dengan kode kustom, hosting sendiri atau cloud, 400+ integrasi. 🔗 n8n-io/n8n #3 datahub-project/datahub (⭐ 12.9k • +10 hari ini • Python) Platform Konteks untuk Tumpukan Data dan AI Anda 🔗 datahub-project/datahub #4 upscayl/upscayl (⭐ 51.2k • +76 hari ini • TypeScript) 🆙 Upscayl - Pengoptimal Gambar AI Gratis dan Sumber Terbuka #1 untuk Linux, MacOS, dan Windows. 🔗 upscayl/upscayl #5 ripienaar/free-for-dev (⭐ 140.2k • +55 hari ini • HTML) Daftar penawaran SaaS, PaaS, dan IaaS yang memiliki tingkatan gratis yang menarik bagi devops dan infradev 🔗 ripienaar/free-for-dev #6 lukasz-madon/awesome-remote-job (⭐ 50k • +99 hari ini • Tidak diketahui) Daftar pilihan pekerjaan dan sumber daya jarak jauh yang luar biasa. Terinspirasi oleh vinta/awesome-python 🔗 lukasz-madon/awesome-remote-job #7 microsoft/Data-Science-For-Beginners (⭐ 37.8k • +47 hari ini • Jupyter Notebook) 10 Minggu, 20 Pelajaran, Ilmu Data untuk Semua! 🔗 microsoft/Data-Science-For-Beginners #8 microsoft/PowerToys (⭐ 140.1k • +84 hari ini • C) Microsoft PowerToys adalah kumpulan utilitas yang meningkatkan produktivitas dan kustomisasi di Windows 🔗 microsoft/PowerToys #9 neovim/neovim (⭐ 103.2k • +41 hari ini • Skrip Vim) Vim-fork yang berfokus pada ekstensibilitas dan kegunaan 🔗 neovim/neovim #10 jellyfin/jellyfin (⭐ 58.7k • +74 hari ini • C#) Sistem Media Perangkat Lunak Gratis - Backend Server & API 🔗 jellyfin/jellyfin #11 run-llama/llama_index (⭐ 52.7k • +23 hari ini • Python) LlamaIndex adalah platform pemrosesan dokumen untuk AI 🔗 run-llama/llama_index #12 anchore/syft (⭐ 9.8k • +14 hari ini • Go) Alat dan pustaka CLI untuk menghasilkan Daftar Material Perangkat Lunak dari citra kontainer dan sistem file 🔗 anchore/syft #13 microsoft/playwright (⭐ 98.7k • +90 hari ini • TypeScript) Playwright adalah kerangka kerja untuk Pengujian dan Otomatisasi Web. Ini memungkinkan pengujian Chromium, Firefox, dan WebKit dengan satu API. 🔗 microsoft/playwright #14 makeplane/plane (⭐ 61.6k • +64 hari ini • TypeScript) 🔥🔥🔥 Alternatif Jira, Linear, Monday, dan ClickUp sumber terbuka. Plane adalah platform manajemen proyek modern untuk mengelola tugas, sprint, dokumen, dan triase. 🔗 makeplane/plane #15 pgvector/pgvector (⭐ 23.5k • +17 hari ini • C) Pencarian kesamaan vektor sumber terbuka untuk Postgres 🔗 pgvector/pgvector ━━━━━━━━━━━━━━━━━━━━━━━ Berlangganan @devrepos untuk repositori GitHub yang sedang tren setiap hari, rangkuman sumber terbuka, dan berita pengembang. Video baru setiap hari yang membahas perangkat lunak sumber terbuka terbaik dan proyek-proyek yang sedang tren di GitHub. [it] Lo stack definitivo per sviluppatori: 23 repository GitHub di tendenza | 28/10/2026 | Dev Repos D... Italiano: cutt.ly 🔥 Nessuno ti ha parlato di questo nuovo repository di IA (Tirocini estivi 2027) Rimani aggiornato sull'ecosistema open source con questa selezione accurata di repository GitHub di tendenza. Da strumenti di sviluppo innovativi a framework rivoluzionari, questi sono i progetti che stanno facendo scalpore nella comunità del software in questo momento. 28 ottobre 2026 Contenuto del video: - I 23 repository GitHub più popolari, classificati in base alle stelle guadagnate oggi - Approfondimenti per sviluppatori e panoramiche dei progetti per ogni repository presentato - Guida interattiva con narrazione AI per ogni progetto open source - Link diretti a tutti i repository qui sotto per un facile accesso ⏱️ INDICE DEI CONTENUTI (Capitoli di YouTube): 00:00 - Introduzione: Strumenti di grande impatto di oggi 00:09 - Panoramica della classifica dei più popolari 00:25 - #1 Summer2027-Internships 00:54 - #2 n8n 01:24 - #3 datahub 01:45 - #4 upscayl 02:08 - #5 free-for-dev 02:33 - #6 awesome-remote-job 02:59 - #7 Data-Science-For-Beginners 03:27 - #8 PowerToys 03:50 - #9 neovim 04:10 - #10 jellyfin 04:33 - #11 llama_index 04:56 - #12 syft 05:18 - #13 playwright 05:46 - #14 plane 06:09 - #15 pgvector 06:28 - #16 awesome 06:59 - #17 runner-images 07:19 - #18 rustdesk 07:43 - #19 lazygit 08:05 - #20 transformers 08:31 - #21 directus 09:02 - #22 gitleaks 09:22 - #23 OpenCore-Legacy-Patcher 09:45 - Outro e Key Punti chiave ━━━━━━━━━━━━━━━━━━━━━━━━ I 23 REPOSITORY PIÙ DI TENDENZA DI OGGI: ━━━━━━━━━━━━━━━━━━━━━━ #1 SimplifyJobs/Summer2027-Internships (⭐ 48.2k • +21 oggi • Python) Offerte di stage per l'estate 2027 in ingegneria del software, data science, IA, analisi quantitativa, gestione del prodotto e hardware. Aggiornato quotidianamente da Simplify e Pitt CSC. #1 SimplifyJobs/Summer2027-Internships (⭐ 48.2k • +21 oggi • Python) Offerte di stage per l'estate 2027 in ingegneria del software, data science, IA, analisi quantitativa, gestione del prodotto e hardware. 🔗 SimplifyJobs/Summer2027-Internships #2 n8n-io/n8n (⭐ 208.9k • +161 oggi • TypeScript) Piattaforma di automazione del flusso di lavoro con codice equo e funzionalità native di IA. Combina la creazione visuale con codice personalizzato, self-hosting o cloud, oltre 400 integrazioni. 🔗 n8n-io/n8n #3 datahub-project/datahub (⭐ 12.9k • +10 oggi • Python) La piattaforma di contesto per il tuo stack di dati e IA 🔗 datahub-project/datahub #4 upscayl/upscayl (⭐ 51.2k • +76 oggi • TypeScript) 🆙 Upscayl - Il miglior strumento gratuito e open source per l'upscaling di immagini basato sull'IA per Linux, MacOS e Windows. 🔗 upscayl/upscayl #5 ripienaar/free-for-dev (⭐ 140.2k • +55 oggi • HTML) Un elenco di offerte SaaS, PaaS e IaaS con piani gratuiti di interesse per DevOps e InfraDev 🔗 ripienaar/free-for-dev #6 lukasz-madon/awesome-remote-job (⭐ 50k • +99 oggi • Sconosciuto) Un elenco curato di fantastiche offerte di lavoro da remoto e risorse. Ispirato da vinta/awesome-python 🔗 lukasz-madon/awesome-remote-job #7 microsoft/Data-Science-For-Beginners (⭐ 37.8k • +47 oggi • Jupyter Notebook) 10 settimane, 20 lezioni, Data Science per tutti! 🔗 microsoft/Data-Science-For-Beginners #8 microsoft/PowerToys (⭐ 140.1k • +84 oggi • C) Microsoft PowerToys è una raccolta di utilità che potenziano la produttività e la personalizzazione su Windows 🔗 microsoft/PowerToys #9 neovim/neovim (⭐ 103.2k • +41 oggi • Vim Script) Fork di Vim focalizzato su estensibilità e usabilità 🔗 neovim/neovim #10 jellyfin/jellyfin (⭐ 58.7k • +74 oggi • C#) Il sistema multimediale software libero - Backend server e API 🔗 jellyfin/jellyfin #11 run-llama/llama_index (⭐ 52.7k • +23 oggi • Python) LlamaIndex è la piattaforma di elaborazione documenti per l'IA 🔗 run-llama/llama_index #12 anchore/syft (⭐ 9.8k • +14 oggi • Go) Strumento e libreria CLI per la generazione di una distinta base software da immagini container e filesystem 🔗 anchore/syft #13 microsoft/playwright (⭐ 98.7k • +90 oggi • TypeScript) Playwright è un framework per il test e l'automazione web. Consente di testare Chromium, Firefox e WebKit con un'unica API. 🔗 microsoft/playwright #14 makeplane/plane (⭐ 61.6k • +64 oggi • TypeScript) 🔥🔥🔥 Alternativa open source a Jira, Linear, Monday e ClickUp. Plane è una moderna piattaforma di gestione progetti per gestire attività, sprint, documentazione e priorità. #14 makeplane/plane (⭐ 61.6k • +64 oggi • TypeScript) 🔥🔥🔥 Un'alternativa open source a Jira, Linear, Monday e ClickUp. Plane è una moderna piattaforma di gestione progetti per gestire attività, sprint, documentazione e priorità. #14 makeplane/plane (⭐ 61.6k • +64 oggi • TypeScript) 🔥🔥🔥 Un'alternativa open source a Jira, Linear, M... [iw] הסטאק האולטימטיבי למפתחים: 23 פרויקטי GitHub חמים | 28/10/2026 | Dev Repos Daily cutt.ly 🔥 אף אחד לא סיפר לכם על מאגר הבינה המלאכותית החדש הזה (קיץ 2027 - התמחויות) הישארו מעודכנים במערכת האקולוגית של קוד פתוח עם מבחר נבחר זה של מאגרי GitHub טרנדיים. מכלי פיתוח חדשניים ועד מסגרות פורצות דרך, אלו הפרויקטים שעושים גלים בקהילת התוכנה כרגע. 28 באוקטובר, 2026 מה יש בסרטון הזה: - 23 מאגרי GitHub הטרנדיים ביותר מדורגים לפי כוכבים שנצברו היום - תובנות מפתחים וסקירות פרויקטים עבור כל מאגר מומלץ - סיור מקיף על כל פרויקט קוד פתוח באמצעות בינה מלאכותית - קישורים ישירים לכל המאגרים למטה לגישה נוחה ⏱️ חותמות זמן (פרקי YouTube): 00:00 - מבוא: הכלים בעלי ההשפעה הגבוהה של היום 00:09 - סקירת טבלת המובילים הטרנדיים 00:25 - #1 קיץ 2027 - התמחויות 00:54 - #2 n8n 01:24 - #3 datahub 01:45 - #4 upscayl 02:08 - #5 free-for-dev 02:33 - #6 awesome-remote-job 02:59 - #7 Data-Science-For-Beginners 03:27 - #8 PowerToys 03:50 - #9 neovim 04:10 - #10 jellyfin 04:33 - #11 llama_index 04:56 - #12 syft 05:18 - #13 playwright 05:46 - #14 plane 06:09 - #15 pgvector 06:28 - #16 awesome 06:59 - #17 runner-images 07:19 - #18 rustdesk 07:43 - #19 lazygit 08:05 - #20 transformers 08:31 - #21 directus 09:02 - #22 gitleaks 09:22 - #23 OpenCore-Legacy-Patcher 09:45 - סיום וסולם נקודות חשובות ━━━━━━━━━━━━━━━━━━━━━━━ 23 המאגרים הטרנדיים ביותר של היום: ━━━━━━━━━━━━━━━━━━━━━━━ #1 SimplifyJobs/Kitchen2027-Internships (⭐ 48.2k • +21 היום • Python) פרסומי התמחויות בהנדסת תוכנה, מדעי נתונים, בינה מלאכותית, כימות, ניהול מוצר וחומרה בקיץ 2027. מתעדכנים מדי יום על ידי Simplify ו-Pitt CSC. 🔗 SimplifyJobs/Summer2027-Internships #2 n8n-io/n8n (⭐ 208.9k • +161 היום • TypeScript) פלטפורמת אוטומציה של זרימת עבודה בקוד הוגן עם יכולות בינה מלאכותית מקוריות. שלב בנייה ויזואלית עם קוד מותאם אישית, אירוח עצמי או ענן, 400+ אינטגרציות. 🔗 n8n-io/n8n #3 datahub-project/datahub (⭐ 12.9k • +10 היום • Python) פלטפורמת ההקשר עבור מחסנית הנתונים והבינה המלאכותית שלך 🔗 datahub-project/datahub #4 upscayl/upscayl (⭐ 51.2k • +76 היום • TypeScript) 🆙 Upscayl - #1 משדרג תמונות בינה מלאכותית חינמי וקוד פתוח עבור לינוקס, MacOS ו-Windows. 🔗 upscayl/upscayl #5 ripienaar/free-for-dev (⭐ 140.2k • +55 היום • HTML) רשימה של הצעות SaaS, PaaS ו-IaaS שיש להן שכבות חינמיות שמעניינות מפתחי פיתוח ופיתוח אינפרא-אדום 🔗 ripienaar/free-for-dev #6 lukasz-madon/awesome-remote-job (⭐ 50k • +99 היום • לא ידוע) רשימה אוצרת של עבודות ומשאבים מדהימים מרחוק. בהשראת vinta/awesome-python 🔗 lukasz-madon/awesome-remote-job #7 microsoft/Data-Science-For-Beginners (⭐ 37.8k • +47 היום • Jupyter Notebook) 10 שבועות, 20 שיעורים, מדעי נתונים לכולם! 🔗 microsoft/Data-Science-For-Beginners #8 microsoft/PowerToys (⭐ 140.1k • +84 היום • C) Microsoft PowerToys הוא אוסף של כלי עזר שמשפרים את הפרודוקטיביות וההתאמה האישית ב-Windows 🔗 microsoft/PowerToys #9 neovim/neovim (⭐ 103.2k • +41 היום • סקריפט Vim) Vim-fork המתמקד בהרחבה ושימושיות 🔗 neovim/neovim #10 jellyfin/jellyfin (⭐ 58.7k • +74 היום • C#) מערכת המדיה של תוכנה חופשית - שרת Backend ו-API 🔗 jellyfin/jellyfin #11 run-llama/llama_index (⭐ 52.7k • +23 היום • Python) LlamaIndex היא פלטפורמת עיבוד מסמכים עבור בינה מלאכותית 🔗 run-llama/llama_index #12 anchore/syft (⭐ 9.8k • +14 היום • Go) כלי וספרייה של ממשק שורת פקודה (CLI) ליצירת רשימת חומרים של תוכנה מתמונות של מכולות ומערכות קבצים 🔗 anchore/syft #13 microsoft/playwright (⭐ 98.7k • +90 היום • TypeScript) Playwright היא מסגרת לבדיקות אינטרנט ואוטומציה. היא מאפשרת בדיקת Chromium, Firefox ו-WebKit עם API יחיד. 🔗 microsoft/playwright #14 makeplane/plane (⭐ 61.6k • +64 היום • TypeScript) 🔥🔥🔥 אלטרנטיבה בקוד פתוח ל-Jira, Linear, Monday ו-ClickUp. Plane היא פלטפורמת ניהול פרויקטים מודרנית לניהול משימות, ספרינטים, מסמכים וטראז'. 🔗 makeplane/plane #15 pgvector/pgvector (⭐ 23.5k • +17 היום • C) חיפוש דמיון וקטורי בקוד פתוח עבור Postgres 🔗 pgvector/pgvector ━━━━━━━━━━━━━━━━━━━━━━━━ הירשמו ל-@devrepos לקבלת מאגרי GitHub יומיים פופולריים, סיכומים בקוד פתוח וחדשות מפתחים. סרטונים חדשים מדי יום המכסים את תוכנות הקוד הפתוח הטובות ביותר ופרויקטים פופולריים ב-GitHub. [ja] 究極の開発者スタック：GitHubでトレンドのレポジトリ23選 | 2026年10月28日 | 開発者レポジトリ・デイリー cutt.ly 🔥 誰も教えてくれなかった、注目のAIリポジトリ（2027年夏期インターンシップ） 厳選された話題のGitHubリポジトリで、オープンソースエコシステムの最新情報を常に把握しましょう。革新的な開発ツールから画期的なフレームワークまで、ソフトウェアコミュニティで今まさに注目を集めているプロジェクトをご紹介します。 2026年10月28日 この動画の内容： - 本日獲得したスター数でランキングされた、GitHubで話題のリポジトリ上位23件 - 各リポジトリの開発者向け解説とプロジェクト概要 - AIによるナレーション付き、各オープンソースプロジェクトの解説 - すべてのリポジトリへの直接リンク（下記参照） ⏱️ タイムスタンプ（YouTubeチャプター）： 00:00 - はじめに：今日の注目ツール 00:09 - トレンドランキング概要 00:25 - #1 Summer2027-Internships 00:54 - #2 n8n 01:24 - #3 datahub 01:45 - #4 upscayl 02:08 - #5 free-for-dev 02:33 - #6 awesome-remote-job 02:59 - #7 Data-Science-For-Beginners 03:27 - #8 PowerToys 03:50 - #9 neovim 04:10 - #10 jellyfin 04:33 - #11 llama_index 04:56 - #12 syft 05:18 - #13 playwright 05:46 - #14 plane 06:09 - #15 pgvector 06:28 - #16 awe

已有 Postgres 的项目做语义检索，可看看开源 pgvector：向量与业务数据放在同一库，支持 SQL 过滤和关联查询。需安装扩展，另选嵌入模型生成向量。先用精确检索作基准；HNSW 等近似索引能提速，但会牺牲召回，带过滤条件时尤其要检查结果是否足量。 pgvector/pgvector

AWS Shipped a DynamoDB API That Stores Everything in Postgres. Read the Tables It Writes - Book: Database Playbook - Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go - My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools - Me: xgabriel.com | GitHub --- On May 20, 2026, two members of the DynamoDB team published ExtendDB: an Apache 2.0 server that speaks the DynamoDB wire protocol and keeps every item in PostgreSQL. Your SDK thinks it is talking to DynamoDB. Underneath sits a Postgres database you can open with psql. That second part is the interesting one. DynamoDB has never let you look at how it stores your items. ExtendDB has to put them somewhere, and that somewhere is a set of ordinary SQL tables. If you have ever drawn a single-table design on a whiteboard and wondered what it "really" is, you can now read the answer in \d. What ExtendDB is, and what it says about itself ExtendDB is written in Rust, maintained by AWS, and described in its README as a clean-room implementation of the DynamoDB wire protocol. The launch announcement called it version 0.1. As of today the releases page lists v0.1.13, published October 1, so it is still a 0.1 line. It covers tables, items, Query and Scan, batch and transactional writes, streams, TTL, and vector search on pgvector. PostgreSQL 14+ is the reference backend. The README also covers MongoDB and mentions SQLite. TLS is mandatory, and every request must be SigV4-signed with credentials ExtendDB issues itself. The launch post is plain about its status: "a v0.1 release for development, testing, and experimentation," and "ExtendDB is not DynamoDB." Run it and point the AWS CLI at it The repo ships a docker-compose.yml that runs Postgres 16 and ExtendDB side by side under Docker Compose and bootstraps on first start. The up and logs commands come from the project's Docker Compose guide: git clone https://github.com/ExtendDB/extenddb.git cd extenddb EXTENDDB_IMAGE=extenddb/extenddb-postgres:latest \ docker compose up -d docker compose logs extenddb-bootstrap The bootstrap logs print the account ID. The admin password defaults to ExtendDBLocalAdmin123 (override it with EXTENDDB_ADMIN_PASSWORD). Create a user, give it a policy, and mint an access key: edb() { docker compose exec extenddb extenddb manage \ --user admin --password ExtendDBLocalAdmin123 "$@" } edb create-user --account-id <account-id> \ --user-name dev edb put-user-policy --account-id <account-id> \ --user-name dev --policy-name full \ --policy-document '{"Version":"2012-10-17", "Statement":[{"Effect":"Allow", "Action":"dynamodb:*","Resource":"*"}]}' edb create-access-key --account-id <account-id> \ --user-name dev The secret is shown once. Access keys start with AKIAEXTENDDB, per the differences doc, so a leaked one is easy to tell apart from a real AWS key. Now trust the self-signed certificate and point the stock AWS CLI at the server: docker compose exec extenddb cat \ /var/lib/extenddb/.extenddb/tls/cert.pem \ > extenddb-cert.pem export AWS_CA_BUNDLE="$PWD/extenddb-cert.pem" export AWS_ACCESS_KEY_ID=<access-key-id> export AWS_SECRET_ACCESS_KEY=<secret-access-key> export AWS_DEFAULT_REGION=us-east-1 aws dynamodb list-tables \ --endpoint-url https://127.0.0.1:18443 That is the whole integration: an endpoint flag and a CA bundle. To skip the flag on every command, the getting-started guide sets AWS_ENDPOINT_URL_DYNAMODB=https://127.0.0.1:18443 instead. The rest of this post assumes you did. A single-table design with one GSI Model a small shop. Customers and their orders share a partition, and a GSI answers "which orders are in status X." Save the index definition as gsi.json: [ { "IndexName": "GSI1", "KeySchema": [ {"AttributeName": "GSI1PK", "KeyType": "HASH"}, {"AttributeName": "GSI1SK", "KeyType": "RANGE"} ], "Projection": {"ProjectionType": "ALL"} } ] Create the table and wait for it. ExtendDB holds new tables in CREATING for 5 seconds by default, which the differences doc lists as configurable: aws dynamodb create-table --table-name Shop \ --billing-mode PAY_PER_REQUEST \ --attribute-definitions \ AttributeName=PK,AttributeType=S \ AttributeName=SK,AttributeType=S \ AttributeName=GSI1PK,AttributeType=S \ AttributeName=GSI1SK,AttributeType=S \ --key-schema \ AttributeName=PK,KeyType=HASH \ AttributeName=SK,KeyType=RANGE \ --global-secondary-indexes file://gsi.json aws dynamodb wait table-exists --table-name Shop Write three items: a profile with no GSI keys, and two orders that carry them. Save as items.json: { "Shop": [ {"PutRequest": {"Item": { "PK": {"S": "CUSTOMER#42"}, "SK": {"S": "PROFILE"}, "plan": {"S": "pro"} }}}, {"PutRequest": {"Item": { "PK": {"S": "CUSTOMER#42"}, "SK": {"S": "ORDER#2026-10-01#A17"}, "GSI1PK": {"S": "STATUS#PAID"}, "GSI1SK": {"S": "2026-10-01#A17"}, "total": {"N": "59.90"} }}}, {"PutRequest": {"Item": { "PK": {"S": "CUSTOMER#42"}, "SK": {"S": "ORDER#2026-10-09#B03"}, "GSI1PK": {"S": "STATUS#SHIPPED"}, "GSI1SK": {"S": "2026-10-09#B03"}, "total": {"N": "12.00"} }}} ] } Then load it and run the two access patterns: aws dynamodb batch-write-item \ --request-items file://items.json # all orders for one customer, oldest first aws dynamodb query --table-name Shop \ --key-condition-expression \ "PK = :pk AND begins_with(SK, :o)" \ --expression-attribute-values \ '{":pk":{"S":"CUSTOMER#42"},":o":{"S":"ORDER#"}}' # every paid order, via the index aws dynamodb query --table-name Shop \ --index-name GSI1 \ --key-condition-expression "GSI1PK = :s" \ --expression-attribute-values \ '{":s":{"S":"STATUS#PAID"}}' Under DynamoDB semantics the first query returns the two orders and skips the profile, and the second returns order A17 only. That is the behavior to check for. None of this is ExtendDB-specific: the same commands run against DynamoDB. Open psql and read the tables The Postgres container publishes no port, so exec into it. List the databases first: docker compose exec postgres psql -U postgres -l You should see a catalog database (extenddb_catalog in the docs) and a separate data database for items. The getting-started guide's example output names it extenddb_catalog_data; confirm it in the list. The catalog maps your table names to the UUIDs used in SQL. Its schema is in 001_schema.sql: -- psql -U postgres -d extenddb_catalog SELECT table_name, table_id FROM tables; SELECT index_name, index_id, propagation_delay_ms FROM indexes; Now switch to the data database. Each DynamoDB table and each index becomes its own SQL table named "_ddb_<id>": -- psql -U postgres -d <data-database> \dt \d "_ddb_<table_id>" SELECT pk, sk_s, jsonb_pretty(item_data) FROM "_ddb_<table_id>"; Here is what to expect from \d, reconstructed from ddl.rs and abridged. Trust your own \d output over this sketch: -- base table "Shop" (string sort key) CREATE TABLE "_ddb_<table_id>" ( pk TEXT COLLATE "C" NOT NULL, sk_s TEXT COLLATE "C", sk_n NUMERIC, sk_b BYTEA, item_data JSONB NOT NULL, PRIMARY KEY (pk, sk_s) ); -- index "GSI1" CREATE TABLE "_ddb_<index_id>" ( pk TEXT COLLATE "C" NOT NULL, sk_s TEXT COLLATE "C", base_pk TEXT COLLATE "C" NOT NULL, base_sk_s TEXT COLLATE "C", item_data JSONB NOT NULL, PRIMARY KEY (pk, base_pk, base_sk_s) -- plus the unused typed sort-key columns ); CREATE INDEX ON "_ddb_<index_id>" (pk, sk_s, base_pk, base_sk_s); Four things are worth staring at. The sort key has three typed slots. The storage design doc says only one of sk_s, sk_n, sk_b is filled per table, picked by the sort key's declared type. Numbers go in NUMERIC, so 10 sorts after 9. That matches DynamoDB, which returns Number sort keys in numeric order. COLLATE "C" lets the index follow DynamoDB's sort order. DynamoDB orders String sort keys by UTF-8 bytes, per the same Query reference. Postgres's C collation sorts by byte values rather than language rules. Setting it on the column lets the B-tree index serve those byte-ordered range scans. A comment in ddl.rs notes the query builders also apply COLLATE "C" to string key predicates and ORDER BY. Older tables without it on the column still return rows in the right order; their index may just not be used as well. Every non-key attribute lives in one JSONB column. plan and total have no column and no index. The design doc says item_data holds the complete item, key attributes included. Look at the jsonb_pretty output yourself to see how types are encoded; that matters before you write any JSON-path SQL against it. The GSI is a second table, and its primary key includes the base key. GSI keys are not unique (many orders can be STATUS#PAID), so the base pk and sort key join the primary key as a tiebreaker. Every write that touches GSI1PK now writes two tables. In DynamoDB you pay that as extra write units on the index. Here you can see the rows. Count the rows in the index table. DynamoDB leaves items without the index key out of a GSI (a sparse index), so the profile should be missing. Checking that is a two-second test of how faithful the adapter is. What a key-value query looks like as SQL The design doc gives the translation table. Equality, <, >, and BETWEEN on the sort key map to the same SQL operators. begins_with does not become LIKE. It becomes a half-open range, with the upper bound made by incrementing the last byte of the prefix. Your first query is roughly this (ExtendDB binds parameters; literals are here for reading): SELECT item_data FROM "_ddb_<table_id>" WHERE pk = 'CUSTOMER#42' AND sk_s >= 'ORDER#' AND sk_s < 'ORDER$' ORDER BY sk_s; # is byte 0x23, so the bound is $ at 0x24. Run EXPLAIN on it if you like. With three rows the planner may pick a sequential scan because the table is tiny. The index is still there. This is the relational reading of single-table design. A partition key is an equality predicate on the leading column of a composite B-tree. A sort key is a range on the second column. A "good access pattern" is any question you can answer with one contiguous slice of that index. A GSI is a second copy of the data, sorted differently, kept in sync by someone. DynamoDB hides that someone. ExtendDB is the someone. Both the design doc and the differences doc say it applies GSI writes after a random delay of up to 10 ms by default. The design doc describes a propagation_delay_ms of 0 as same-transaction, while the differences doc still calls synchronous GSIs a future feature. A filter on plan or total has no column to use. The rows are read, then discarded. DynamoDB's Query reference says the same about its own filters: they run after the read, and consumed capacity is the same with or without them. ExtendDB pays the same way: Postgres reads every row in the slice before dropping the ones that miss. Where it fits, and why it is not your way off DynamoDB The uses AWS lists are local development, CI, on-premises and air-gapped deployments, and multi-cloud setups where Postgres is available. For CI, the draw is concrete: a real Postgres you already know how to run, pg_dump for fixtures, and the AWS SDK pointed at it unchanged. One of the launch authors wrote on LinkedIn, as quoted by InfoQ, that in the current version it "doesn't differ that much" from DynamoDB Local "except you can use Postgres." A migration target is a different job. The differences doc lists what is missing or behaves differently today: - Global tables and PartiQL are not implemented and return UnknownOperationException. DAX is listed as not applicable. - On Postgres, contended TransactWriteItems usually queue and commit instead of returning TransactionConflict. A test that expects TransactionConflict won't get one here, and code that never handles it will look fine until production. - On-demand tables get a fixed burst (4,000 WCU / 12,000 RCU) with no auto-scaling, and throttling can be switched off entirely. - Import and export use local paths, not S3. - The README says running more than one serve against the same catalog is not supported in this release, so there is no horizontal scaling story yet. Performance is an open question. InfoQ quotes one Reddit user reporting about 300 ms p90 on update_item at a concurrency of 10 on a 16-core MacBook and calling it "not good (yet)." That is a single unverified report, not a benchmark. I haven't run ExtendDB myself, so measure on your own workload before you lean on it. And the operational trade is the one the launch post states outright: you own the database's "availability, backups, and maintenance." Leaving DynamoDB for this means trading a managed service for a self-hosted Postgres plus a 0.1 adapter in front of it. If what you actually want is Postgres, model for Postgres directly and skip the JSONB-in-a-key-value-shape layer. --- If this was useful Reading \d on a DynamoDB table is a fast way to see what an access pattern costs: which column carries the equality, which carries the range, and which data has no index at all. The Database Playbook works through that decision for Postgres, DynamoDB, Redis, SQLite and the rest, so you can pick the store from the access patterns instead of the other way round. 

From Rows to Vectors: pgvector inside Postgres --- title: "From Rows to Vectors: pgvector inside Postgres" published: true description: "What a vector database does, how HNSW and IVFFlat work, and the traps of running pgvector inside the Postgres you already run." tags: postgres, pgvector, node, ai --- Say your product needs search that understands meaning. A user types "the tax due when you sell shares at a profit" and expects the page on capital gains tax, even though none of those words appears in its title. The usual next step is a new piece of infrastructure: Pinecone, Qdrant, Milvus or Weaviate, with its own bill, its own SLA and a sync job to keep it in step with your real data. There is another option: keep the embeddings in pgvector, inside the PostgreSQL database you already run. This article explains what a vector database does, how its indexes work, and what to watch for when you run one inside Postgres, including the traps that are easy to ship without noticing. --- Two kinds of questions A relational database answers "which rows are equal to this?" SELECT * FROM orders WHERE customer_id = 42; The answer is exact. A row matches, or it does not. A vector database answers "which rows are like this?" SELECT id, body FROM documents ORDER BY embedding <=> $1 LIMIT 5; The answer is a ranking. Every row sits some distance away from the query, and you ask for the closest few. Everything else in this article follows from that one change of contract. | | Relational database | Vector database | | --- | --- | --- | | Stores | rows of typed columns | vectors, plus metadata | | Asks | equal, range, join | the k nearest to a query vector | | Index | B-tree, hash: exact lookups | HNSW, IVF: approximate search | | Answer | an exact set of rows | a ranked list that may miss a few | | Built for | transactions, constraints, joins | similarity over millions of vectors | | Examples | PostgreSQL, MySQL | Pinecone, Qdrant, Milvus, Weaviate | pgvector puts the right-hand column inside the left-hand one. --- From meaning to numbers An embedding model turns a piece of content into a fixed-length list of numbers. It is trained so that similar meanings produce similar numbers. OpenAI's text-embedding-3-small returns 1,536 numbers by default, and text-embedding-3-large returns 3,072. Both accept a dimensions parameter to return fewer (OpenAI embeddings guide). Two properties matter in practice: - Fixed length. ** A single word and a full page produce the same number of dimensions. - One model for both sides. ** Stored rows and incoming queries must go through the same model, with the same settings. Swap the model and every stored vector needs re-embedding. Meaning as a place Picture those numbers as coordinates. Real embeddings have 1,536 axes, but two are enough to get the idea. "cat", "dog" and "puppy" land close together. "pizza", "pasta" and "bread" form their own cluster. "capital gains tax", "CGT" and "tax on a share sale" sit in a third. Search becomes geometry. Embed the query with the same model, then ask for its nearest neighbours. A query for "kitten" finds "cat" and "puppy", although "kitten" is a different word from both. No keyword matching is involved. "Near" needs a definition pgvector ships several distance operators (pgvector README, Querying): | Operator | Distance | What it measures | | --- | --- | --- | | <-> | L2 (Euclidean) | the straight-line gap between the two points | | <=> | cosine | the angle between the vectors; length is ignored | | <#> | negative inner product | angle and length, negated so that smaller means closer | | <+> | L1 (taxicab) | the sum of the per-axis differences | | <~>, <%> | Hamming, Jaccard | for binary (bit) vectors | > Note: <#> returns the negative inner product because Postgres only supports ascending-order index scans on operators (pgvector README, Getting Started). Multiply by -1 if you want the real value. The pgvector README states that OpenAI embeddings are normalised to length 1, and recommends inner product for best performance on normalised vectors (pgvector README, Exact Search). For unit-length vectors, inner product ranks results in the same order as cosine. --- Why a B-tree can't help A B-tree handles equality and range queries on data that can be sorted into an order (PostgreSQL docs, Index Types). WHERE id = 42 takes a few hops down the tree and lands on the row. "Nearest to this vector" has no fixed order. Every query has its own centre, so nothing can be sorted in advance. Without an approximate index, pgvector performs exact nearest neighbour search: it compares the query against every row (pgvector README, Indexing). The cost adds up quickly. Take one million rows of 1,536-dimensional vectors: - 1.5 billion multiply-adds per query (1,000,000 × 1,536). - About 6.2 GB read per query. ** pgvector stores each vector in 4 × dimensions + 8 bytes, so 6,152 bytes per row (pgvector README, Vector Type). Exact search returns perfect recall, and its cost grows in a straight line with the table. Approximate nearest neighbours Vector indexes give up a little accuracy to stop reading everything. The measure for that accuracy is recall: the share of the true k nearest neighbours that actually come back. Two things follow: - Recall is a dial. ** Each index type has a query-time setting that trades speed for recall. You choose where to sit on the curve. - Adding an index can change your results. The pgvector README says it directly: you will see different results for queries after adding an approximate index (pgvector README, Indexing). A test that passed against a sequential scan can fail the day the index ships. --- IVFFlat: cluster first, then search a few clusters IVFFlat divides the vectors into lists, each grouped around a centroid, and a query searches only the lists closest to it. The number of lists it searches is probes, and the default is 1 (pgvector README, IVFFlat). The lists come from k-means over the rows present at build time; the index build reports a performing k-means phase. The weakness is at the borders. If the true nearest neighbour sits just over the edge of a neighbouring list, a query with probes = 1 never looks there. The README gives these starting points: - lists = rows / 1000 for up to 1M rows, and sqrt(rows) above that. - probes = sqrt(lists). - Create the index after the table has some data. CREATE INDEX ON documents USING ivfflat (embedding vector_cosine_ops) WITH (lists = 100); SET ivfflat.probes = 10; The README's troubleshooting section names the symptom too: an IVFFlat index created with too little data for its number of lists returns fewer results (pgvector README, Troubleshooting). An easy way to hit this. ** Indexes usually arrive through migrations, and migrations usually run before any data exists. An IVFFlat index created that way builds its lists from an empty table. Leave probes at its default, and every query searches one list out of 100. The fix is a REINDEX once the data is loaded, and an explicit SET ivfflat.probes per query. Better still, use HNSW, which has no training step. --- HNSW: a layered graph HNSW (Hierarchical Navigable Small World) comes from a paper by Malkov and Yashunin (arXiv 1603.09320). It builds a graph in layers. The top layer has few nodes and long links; each layer below has more nodes and shorter links, down to layer 0, which holds every vector. A search starts at the top, hops to whichever neighbour is closer to the query, drops a layer, and repeats. Its settings and their defaults (pgvector README, HNSW): - m = 16: the maximum number of connections per layer. - ef_construction = 64: the size of the candidate list while building. - hnsw.ef_search = 40: the size of the candidate list per query. This is the recall dial. HNSW has no training step, so you can create it on an empty table. CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops); SET hnsw.ef_search = 100; Builds are much faster when the graph fits in maintenance_work_mem, and Postgres prints a notice when it no longer does (pgvector README, Index Build Time). --- Choosing between them All rows below come from the pgvector README. | | HNSW | IVFFlat | | --- | --- | --- | | Structure | multilayer graph | lists around centroids | | Training | none: can build on an empty table | k-means: build after loading | | Build | slower, more memory | faster, less memory | | Speed vs recall | better | lower | | Query dial | hnsw.ef_search, default 40 | ivfflat.probes, default 1 | | Build dials | m = 16, ef_construction = 64 | lists | My default is HNSW, unless build time or memory is the constraint. It gives a better speed-recall trade-off, and it removes the empty-table trap entirely. --- pgvector: a vector database inside Postgres pgvector is an open-source Postgres extension; the README's install instructions reference version 0.8.7 at the time of writing (pgvector README, Installation). It adds vector types, distance operators and the two index types above. Everything you already rely on stays: ACID transactions, joins, point-in-time recovery, replication and the query planner. On AWS, Aurora PostgreSQL supports it (AWS announcement: pgvector 0.8.0 on Aurora PostgreSQL). CREATE EXTENSION vector; --- Types and limits One 1,536-dimension embedding takes this much space in each type. Storage formulas and index limits come from the pgvector README reference and its HNSW section. | Type | Element | Bytes for 1,536 dims | Index up to | | --- | --- | --- | --- | | vector | float32 | 6,152 (4 × d + 8) | 2,000 dims | | halfvec | float16 | 3,080 (2 × d + 8) | 4,000 dims | | bit | 1 bit, lossy | 200 (d ÷ 8 + 8) | 64,000 dims | | sparsevec | non-zero elements only | 8 × non-zero + 16 | 1,000 non-zero, HNSW only | Vectors can store up to 16,000 dimensions; only indexing is limited. A 3,072-dimension model such as text-embedding-3-large cannot be indexed as vector, but it can be indexed as halfvec (pgvector README FAQ). > Note: bit keeps only one bit per dimension. Use it as a fast first pass and re-rank with the full vector (see scaling below). A table, an index, a query CREATE TABLE documents ( id bigserial PRIMARY KEY, body text NOT NULL, embedding vector(1536) NOT NULL ); CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops); -- the five nearest to a query vector SET hnsw.ef_search = 100; SELECT id, body FROM documents ORDER BY embedding <=> $1 LIMIT 5; Four details that cost people time: - The dimension is part of the column type. A vector(1536) column holds 1,536-dimensional vectors; to mix dimensions, you need the unsized vector type (pgvector README FAQ). - The index serves one distance function. The README says to add an index for each distance function you want to use (pgvector README, HNSW). An index built with vector_cosine_ops speeds up <=> only. - hnsw.ef_search is per session. Use SET LOCAL inside a transaction to change it for one query (pgvector README, Query Options). - The index needs both ORDER BY and LIMIT, and the ORDER BY must be the distance operator itself in ascending order. ORDER BY 1 - (embedding <=> $1) DESC skips the index (pgvector README, Troubleshooting). Why cosine here, after I said inner product is fastest? For unit-length vectors, the two give identical rankings, and cosine stays correct if a future model does not normalise its output. I chose safety over a small speed gain. The same query from Node.js The pgvector npm package supports node-postgres, Knex.js, Kysely, Prisma, Drizzle ORM and several other libraries (pgvector-node README). npm install pgvector pg openai import OpenAI from 'openai' import pg from 'pg' import pgvector from 'pgvector/pg' const question = 'the tax due when you sell shares at a profit' const client = new pg.Client() await client.connect() await pgvector.registerTypes(client) // reads OPENAI_API_KEY from the environment const { data } = await new OpenAI().embeddings.create({ model: 'text-embedding-3-small', input: question, }) const { rows } = await client.query( `SELECT id, body FROM documents ORDER BY embedding <=> $1 LIMIT 5`, [pgvector.toSql(data[0].embedding)], ) Where each part comes from: - registerTypes and toSql follow the pgvector-node README, node-postgres section. With a pool, call registerTypes in the pool's onConnect hook. - registerType (singular) is deprecated since pgvector-node 0.3.0 (pgvector-node README, Upgrading). - new OpenAI() reads OPENAI_API_KEY from the environment (openai-node README). - The response's data array holds one item per input, each with an embedding field (OpenAI API reference, Create embeddings). --- Production trap 1: WHERE runs after the index scan This one bites quietly. With an approximate index, filtering is applied after the index is scanned. The pgvector README gives the numbers: if a condition matches 10% of rows, HNSW with the default ef_search of 40 leaves only about 4 matching rows on average (pgvector README, Filtering). Ask for 10, and you get about 4. No error, no warning: just fewer results. -- asks for 10, typically gets about 4 back once an HNSW index exists SELECT id, body FROM documents WHERE course_id = 123 ORDER BY embedding <=> $1 LIMIT 10; Since pgvector 0.8.0, iterative index scans fix this (pgvector CHANGELOG). When enabled, the scan keeps reading the index until enough results are found, or until it reaches hnsw.max_scan_tuples (default 20,000) or ivfflat.max_probes (pgvector README, Iterative Index Scans). SET hnsw.iterative_scan = strict_order; -- or, trading exact ordering for recall: SET hnsw.iterative_scan = relaxed_order; -- IVFFlat supports relaxed ordering only SET ivfflat.iterative_scan = relaxed_order; Other options from the README: an index on the filter column for conditions that match a low percentage of rows, a partial index when you filter by a few distinct values, and partitioning when you filter by many (pgvector README, Filtering). For tenant isolation, it recommends list partitioning or separate tables (pgvector README, Multitenancy). Why this one survives code review. ** A filtered similarity query on a table with no vector index returns exact results, because Postgres scans everything. The day someone adds an index for speed, the same query starts returning fewer rows, with no error. A test that runs against a small, unindexed table will not catch it. If you filter, decide on iterative scans before you add the index. --- Production trap 2: keywords and meaning need each other Vector search misses exact identifiers. Search for a course code or a regulation number and the embedding treats it as noise. Full-text search has the opposite gap: it misses paraphrases. Hybrid search runs both and merges the results. The pgvector README suggests combining it with Postgres full-text search, using Reciprocal Rank Fusion or a cross-encoder to merge (pgvector README, Hybrid Search). The merge is the hard part, because the scores live on different scales. Cosine distance and ts_rank cannot be added together. Reciprocal Rank Fusion (RRF) sidesteps that by combining positions instead of scores. The constant k smooths the score so that a first place does not dominate: score(doc) = Σ 1 / (k + rank) With k = 50, the default rrf_k in Supabase's hybrid search guide: | Doc | Full-text rank | Vector rank | RRF score | | --- | --- | --- | --- | | A | 2 | 1 | 1/52 + 1/51 = 0.0388 | | B | 1 | 3 | 1/51 + 1/53 = 0.0385 | | C | not ranked | 2 | 1/52 = 0.0192 | | D | 3 | not ranked | 1/53 = 0.0189 | Documents A and B appear in both lists, so they rise to the top. A document that only one method found still scores, just lower. In Postgres, both halves live in the same table. Keep a tsvector column next to the vector column, run the two ranked queries as CTEs, and join them on the document ID. Supabase's guide shows a complete SQL function built this way. --- Production trap 3: scaling before you buy The usual argument for a dedicated vector store is scale. Before taking on another service, pull the Postgres levers first. The README lists them (pgvector README, Scaling); the order is mine: 1. halfvec columns. Half the bytes per vector, so a smaller working set. 2. Binary quantization for the index, then re-rank the shortlist at full precision. 3. maintenance_work_mem large enough for HNSW to build in memory. 4. A bigger instance: more memory, CPU and storage. 5. Read replicas, then Citus or PgDog to shard. The binary quantisation pattern, adapted from the README: CREATE INDEX ON documents USING hnsw ((binary_quantize(embedding)::bit(1536)) bit_hamming_ops); SELECT * FROM ( SELECT * FROM documents ORDER BY binary_quantize(embedding)::bit(1536) <~> binary_quantize($1) LIMIT 20 ) shortlist ORDER BY embedding <=> $1 LIMIT 5; A dedicated store earns its place when those levers are pulled, and your recall or latency targets still miss, or when vector traffic has to scale independently of the transactional database. I looked for an independent benchmark that names the size where Postgres stops being enough, and did not find one. Measure recall and latency on your own data before deciding. The README shows how: compare approximate results with exact search by running the query with SET LOCAL enable_indexscan = off (pgvector README, Monitoring). --- When you don't need an index at all Not every vector table needs an approximate index. Two common shapes: - Few-shot examples for an LLM. ** You pick the most similar past examples to put in a prompt. These tables are often small, so exact search with no index is fast enough, and it gives perfect recall for free. - A document library for retrieval. Uploaded documents are chunked and embedded, with a full-text column beside each vector, ready for hybrid search. This is the shape that grows, and where the index decisions above start to matter. Start without an index, measure latency, and add one when the numbers ask for it. When you do, revisit every filtered query first. --- Three things to take home 1. A vector database answers "like this". Embeddings turn meaning into distance; nearest neighbours turn distance into results. 2. Approximate means a dial. ef_search and probes trade speed for recall. Treat the defaults as a starting point and tune from there. 3. Start in Postgres; earn the next database. pgvector keeps vectors beside the rows they describe, in a system you already back up, monitor and understand. Measure recall and latency before adding a service to run. And you? Did you start with a dedicated vector store, or keep everything in Postgres? If you have hit a recall or latency wall with pgvector, I would like to know the table size and the setting that broke it. Drop a comment if you have questions. Bruno Souza, Software Engineer --- Sources - pgvector README: types, operators, HNSW, IVFFlat, filtering, iterative scans, hybrid search, scaling, monitoring - pgvector CHANGELOG: 0.7.0 types, 0.8.0 iterative scans - pgvector-node README: Node.js usage, supported libraries, 0.3.0 upgrade notes - OpenAI embeddings guide: model dimensions and the dimensions parameter - OpenAI API reference, Create embeddings: response shape - openai-node README: client construction and API key - PostgreSQL docs, Index Types: what a B-tree handles - Malkov and Yashunin, Efficient and robust approximate nearest neighbour search using Hierarchical Navigable Small World graphs - Supabase docs, hybrid search: RRF with rrf_k = 50 - AWS: pgvector 0.8.0 support in Aurora PostgreSQL Facts checked on 20 October 2026.