- Can I use this package directly in Laravel without Symfony dependencies?
- No, this package is Symfony-first and requires Symfony’s `StoreInterface`. However, you can wrap it in a Laravel `ServiceProvider` to expose a custom interface (e.g., `SupabaseStore`) while injecting the Symfony `HttpClient` or `SupabaseClient`. This avoids pulling in full Symfony components but requires manual adapter work.
- What Laravel AI packages (e.g., symfonycasts/laravel-ai) work with this store?
- This store bridges with Symfony AI’s `StoreInterface`, so you’d need to implement a Laravel-specific adapter (e.g., a `VectorStore` interface) to integrate with `symfonycasts/laravel-ai` or `tighten/laravel-ai`. The underlying Supabase RPC (`match_documents`) handles vector similarity search, but the glue code is your responsibility.
- Does this support MySQL or SQLite instead of PostgreSQL?
- No, this package relies on Supabase’s PostgreSQL + pgvector. For MySQL/SQLite Laravel apps, you’d need to use Supabase’s REST API (losing pgvector optimizations) or self-host pgvector separately. Alternatives like Elasticsearch or Milvus may fit better for non-PostgreSQL stacks.
- How do I configure the store for Laravel’s service container?
- Register the store in a Laravel `ServiceProvider` by binding it to a custom class (e.g., `SupabaseStore`). Inject the Symfony `HttpClient` or a `SupabaseClient` (e.g., `supabase-php/supabase`) into the constructor. Example: `$this->app->singleton(SupabaseStore::class, fn($app) => new SupabaseStore($app->make(SupabaseClient::class)));`.
- What’s the performance impact of Supabase RPCs vs. direct pgvector queries?
- Supabase RPCs (e.g., `match_documents`) introduce network latency compared to direct pgvector queries. Benchmark your use case: RPCs simplify setup but may add ~50–200ms round-trip time. For low-latency needs, self-hosted pgvector or a local vector DB (e.g., Qdrant) could be better.
- Are there Laravel-specific examples or migration guides for existing vector data?
- No, this package lacks Laravel examples. To migrate data (e.g., from Redis/Elasticsearch), use Supabase’s REST API or raw PostgreSQL queries to insert embeddings into a `vector` column. Schema changes require manual RPC adjustments if you deviate from Supabase’s `match_documents` format.
- How do I handle Supabase downtime or rate limits in Laravel?
- Implement a fallback strategy: cache responses locally (e.g., Redis) or queue failed RPC calls for retry. Supabase’s free tier has [rate limits](https://supabase.com/pricing), so monitor usage. For production, consider a local pgvector instance or a multi-cloud Supabase setup.
- What are the cost implications at scale (e.g., 10K+ QPS)?
- Supabase’s pricing scales with storage, compute, and API calls. At high volumes, costs may exceed self-hosted pgvector or alternatives like Milvus/Weaviate. Audit your query patterns: RPCs (`match_documents`) are efficient but may hit limits faster than direct SQL. Test with Supabase’s [pricing calculator](https://supabase.com/pricing).
- Can I use this with Laravel Scout for hybrid search (keyword + vector)?
- Not natively. Scout uses Elasticsearch, while this package relies on Supabase pgvector. For hybrid search, combine Scout (keyword) with this store (vector) via a custom search pipeline, or use a unified vector search engine like Weaviate or Milvus that supports both.
- What’s the maintenance effort for long-term Laravel integration?
- Moderate to high. Since this is Symfony-first, Laravel-specific updates (e.g., container integration) require manual maintenance. Watch for Symfony AI breaking changes. For lower friction, consider forking the package as `laravel-ai-supabase-store` or contributing a Laravel adapter to the upstream repo.