mirror of
https://github.com/supabase/supabase.git
synced 2026-10-18 15:49:09 +03:00
deployment section
This commit is contained in:
1 parent
96b688ed89
commit
e4fb400f39
2 files changed
+31
-3
No files matched your search
@@ -54,7 +54,7 @@ Or, more specifically:
|
||||
create table vecs.docs (
|
||||
id text primary key,
|
||||
vec vector(3) not null,
|
||||
metadata jsonb not null default '{}'::jsonb,
|
||||
metadata jsonb not null default '{}'::jsonb
|
||||
);
|
||||
```
|
||||
|
||||
@@ -124,11 +124,39 @@ or [OpenAI integration example](https://supabase.github.io/vecs/integrations_ope
|
||||
## Deploying with Supabase
|
||||
|
||||
As usual, if you combine [supabase/vecs](https://github.com/supabase/vecs) with the rest of Supabase, you get more than the sum of the parts.
|
||||
Once you're happy with your vecs collection, you can make it acessible to your front-end and supabase-js by exposing the collection as a view
|
||||
Once you're happy with your vecs collection, you can make it acessible to your front-end through a supabase client library by exposing the collection as a view
|
||||
in your public schema.
|
||||
|
||||

|
||||
|
||||
For example, you could create a view
|
||||
|
||||
```sql
|
||||
create view public.docs as
|
||||
select
|
||||
id,
|
||||
embedding,
|
||||
metadata, # Expose the metadata as JSON
|
||||
(metadata->>'url')::text as url # Extract the URL as a string
|
||||
from
|
||||
vecs.docs
|
||||
```
|
||||
|
||||
And then access it with the supabase-js client library within your applications:
|
||||
|
||||
```js
|
||||
const { data, error } = await supabase
|
||||
.from('docs')
|
||||
.select('id, embedding, metadata')
|
||||
.eq('url', '/hello-world')
|
||||
```
|
||||
|
||||
For more deployment options, including enterprise scalable architecture, check out the [engineering for scale guide](https://supabase.com/docs/guides/ai/engineering-for-scale#simple-workloads).
|
||||
|
||||
|
||||
## Future ideas
|
||||
|
||||
Currently, `vecs` is unopinionated about where vectors come from or how their produced. While there will always be a need for generic vector
|
||||
Currently, `vecs` is unopinionated about where vectors come from or how they're produced. While there will always be a need for generic vector
|
||||
storage and querying, its becoming clear that text and image vectorization make up +95% of usage. That gives us the opportunity to
|
||||
streamline those workflows for users.
|
||||
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 66 KiB |
Reference in new issue
Block a user