Do I still need Pinecone or another vector database?

For most AI SaaS, no. pgvector stores embeddings inside the same Supabase Postgres as your users and content, so retrieval-augmented generation runs as one SQL query with no second service to sync or pay for. A dedicated vector database earns its place once you are past a few million vectors or need very high query throughput. Adding one before that is a bill and a sync problem you do not need yet.

What does the Next.js + Supabase AI boilerplate actually include?

Next.js 16 App Router with Server Actions, Supabase auth and Postgres, pgvector wired for embeddings, Row Level Security policies for the common ownership patterns, Stripe checkout, a credit system, and edge routes that stream LLM responses from OpenAI or Claude. The code is typed and the schema is migration-based.

Is pgvector fast enough for production?

Yes, within range. With an HNSW index, similarity search over a few hundred thousand to a few million embeddings returns in single-digit to low double-digit milliseconds on a modest instance. You trade some recall for speed by tuning the index, and you manage index memory yourself. Past that scale a purpose-built store will be faster.

Can I run everything on the edge runtime?

No, and you should not try. The edge is the right place to stream chat completions because it has no cold start and low time-to-first-byte. It cannot run Node-only libraries, it has shorter timeouts, and it needs a connection pooler to talk to Postgres. Keep Stripe webhooks, background jobs, and heavy processing on the Node runtime. The boilerplate splits routes this way by default.

Is it a one-time payment?

Yes. The boilerplate is a one-time $89.99 with lifetime updates and a secure Stripe checkout. There is no subscription and no per-seat fee for the code.

AI SaaS starter kit

Next.js + Supabase AI boilerplate with pgvector and Row Level Security

This is the stack I reach for when I want an AI feature in production by the weekend: Next.js on the front, Supabase Postgres underneath, and the model plumbing already wired. The page below is honest about where a Next.js + Supabase AI boilerplate saves you real days and where it quietly costs you later. pgvector handles embeddings inside the same database that holds your users, so retrieval-augmented generation does not need a second service. Row Level Security keeps one customer from reading another customer’s data. Checkout is a one-time $89.99.

Get the boilerplate Compare it with other kits

$89.99 one-time. Lifetime updates. Secure Stripe checkout.

What’s inside the Next.js + Supabase AI boilerplate

Three pieces of this Next.js AI starter kit do most of the heavy lifting. If you are building a conversational product, for example a Character.ai-style chat app, the same pieces become long-term memory and per-user history.

pgvector embeddings

Embeddings live in the same Postgres as your users and content. Retrieval-augmented generation is one SQL call through a match_documents function, with no second database to keep in sync.

Edge streaming routes

The chat route runs on the edge runtime, so tokens from OpenAI or Claude start streaming with no cold start. Node-only work stays on the Node runtime where it belongs.

Row Level Security

Authorization lives on the table, not scattered through your query code. A user reads their own rows and nobody else’s, enforced by Postgres on every request.

Building that chat product is a real worked example. The architecture for a Character.ai-style chat app leans on all three: pgvector for conversation memory, edge routes for streaming replies, and RLS so one user never sees another user’s threads.

Honest tradeoffs

pgvector vs a hosted vector database

Keeping embeddings in Postgres is the default here, and for most teams it is the right one. It is not the right one for everybody, so here is the line.

Where pgvector wins

+One database to back up and pay for. Embeddings sit beside the rows they describe.
+You can join a vector match against users, billing, and permissions in a single query.
+Row Level Security covers vector rows too, so search cannot return another tenant’s data.
+No sync pipeline. Nothing to reconcile when an embedding write succeeds but the mirror fails.

Where a dedicated store wins

-Tens of millions of vectors at high query throughput, where purpose-built indexes pull ahead.
-Workloads where the vector traffic dwarfs the relational traffic and deserves its own scaling.
-Teams that want managed recall and latency tuning instead of running HNSW indexes themselves.

If you searched for a supabase pgvector starter, this is the part that decides it: at launch and for a long stretch after, a few hundred thousand to a few million embeddings with an HNSW index sit comfortably on a modest Supabase instance and return matches in single-digit milliseconds. Pinecone earns its bill when you outgrow that, not on day one. Adding a managed vector service early is a second invoice and a sync problem before you have the traffic that would justify either. Start on pgvector, measure, and split it out only when the numbers say so. The full feature list and how it stacks up against other kits is on the best AI SaaS boilerplates roundup.

Row Level Security, and the parts people forget

Row Level Security pushes the access check down into Postgres. Instead of remembering a where user_id = auth.uid() on every query and shipping a leak the one time you forget, the policy lives on the table and the database applies it to every read and write, including the vector search function. The boilerplate ships policies for the common shape, where a user owns their rows, plus tested patterns for shared and team data.

It is not a free pass. Policies evaluate per row, so a heavy policy on a hot path adds latency you can measure. The service-role key bypasses RLS entirely, which is the point of it for server jobs and also the thing that ends your week if that key leaks into the browser. Keep it server-side, scope your anon key, and read the policies before you change a table. RLS removes a whole class of mistakes. It does not remove the need to think.

The edge runtime tradeoff

Streaming is where the edge runtime pays off. A chat completion route on the edge starts sending tokens with low time-to-first-byte and no cold start, which is the difference between an AI feature that feels alive and one that spins. That is why the boilerplate puts the model-streaming routes there by default.

The edge is not Node, though, and that catches people. Libraries that reach for Node APIs (parts of some SDKs, native crypto, the filesystem) will not run on it. Timeouts are shorter, so a long generation or a big export can get cut off. And every edge invocation that touches Postgres needs the Supabase connection pooler, because the edge opens many short-lived connections that would otherwise exhaust the database. The fix is boring and correct: stream from the edge, and keep Stripe webhooks, background jobs, and heavy processing on the Node runtime. The boilerplate already splits routes this way, so the limitation does not surprise you in production.

The vector search this ships with

This is the helper from lib/supabase/vectors.ts. It calls a Postgres function that does the cosine match inside the database and returns typed rows, so the embedding never leaves the same instance your data lives in.

lib/supabase/vectors.ts

// Example: Search your vector embeddings natively in Supabase
export async function searchDocuments(query: string) {
  const embedding = await generateEmbedding(query);

  const { data, error } = await supabase
    .rpc('match_documents', {
      query_embedding: embedding,
      match_threshold: 0.78, // Semantic similarity threshold
      match_count: 5         // Number of chunks to retrieve
    });

  if (error) throw error;
  return data;
}

Typed and ready to use. The match_documents function and its HNSW index ship as migrations.

After you build

Where to launch your AI app after you ship

Shipping the code is half the job. Getting the first users is the other half, and that is what the rest of SaaSCity is for.

Once the app is live, a handful of launch and directory channels are worth your time. The list below shows each one’s current Ahrefs Domain Rating so you can judge link value before you spend an afternoon on a submission. A high-DR dofollow link moves the needle. A nofollow listing is traffic, not authority. Knowing which is which saves you from the spammy submit-to-500-sites advice that wastes a weekend.

01
There's An AI For Thattheresanaiforthat.com
DR77
dofollowPaid
The biggest AI-tool directory by traffic, and the listing link is dofollow, so it carries real weight. It is paid, and the fee plus the queue have grown as it got popular. Worth it if your product is genuinely an AI tool people search for. If you built a developer utility that happens to call an LLM, your audience is not here and the fee is hard to justify.
Audience
Largest AI-tool directory by traffic
Cost
Paid listing, fee has climbed over time
Best for
Genuine AI tools, not dev tools that merely call an API
02
Future Toolsfuturetools.io
DR68
dofollowFree
A smaller, hand-curated AI directory with a dofollow link and an audience that actually clicks through to try tools. Free to submit, which puts the risk close to zero. The reviewer is selective, so a clear one-line description and a working demo matter more here than they do on pay-to-list sites.
Audience
Curated AI-tool readers, hand-reviewed
Cost
Free to submit
Best for
Consumer-facing AI apps with a live demo
03
DevHuntdevhunt.org
DR62
dofollowFree + Paid
A launch site aimed at developer tools rather than consumer apps. The link is dofollow and the base submission is free. If the thing you shipped on this stack is an API, SDK, or dev utility, this fits better than the general AI directories, because the crowd here reads changelogs and tries betas.
Audience
Developer-tool launch crowd
Cost
Free tier, optional paid boosts
Best for
Dev tools and APIs built on this stack
04
Product Huntproducthunt.com
DR91
nofollowFree
Still the widest reach for a launch day, but read the link type before you plan SEO around it: it is nofollow, so treat Product Hunt as traffic, feedback, and social proof, not as a backlink. Pick a single launch date, line up your first few comments, and do not spread submissions across a slow week.
Audience
Broad launch-day traffic and press eyes
Link
nofollow, so it is reach, not authority
Best for
A coordinated launch day, not evergreen backlinks

Domain Rating by Ahrefs. DR figures last refreshed 2026-06-14. The directory list starts from a launchdirectories export and is then checked by hand: I open each listing page and confirm the outbound link is actually dofollow before it earns that label, because plenty of directories advertise dofollow and quietly ship nofollow.

For the full, filtered lists see the best AI directories, directories for developer tools, and the general SaaS directory rankings. When you are ready, submit your product. If you want the full sequence from empty repo to launched app, read build and launch an AI SaaS in a weekend.

Questions founders ask before buying

Do I still need Pinecone or another vector database?: For most AI SaaS, no. pgvector stores embeddings inside the same Supabase Postgres as your users and content, so retrieval-augmented generation runs as one SQL query with no second service to sync or pay for. A dedicated vector database earns its place once you are past a few million vectors or need very high query throughput. Adding one before that is a bill and a sync problem you do not need yet.
What does the Next.js + Supabase AI boilerplate actually include?: Next.js 16 App Router with Server Actions, Supabase auth and Postgres, pgvector wired for embeddings, Row Level Security policies for the common ownership patterns, Stripe checkout, a credit system, and edge routes that stream LLM responses from OpenAI or Claude. The code is typed and the schema is migration-based.
Is pgvector fast enough for production?: Yes, within range. With an HNSW index, similarity search over a few hundred thousand to a few million embeddings returns in single-digit to low double-digit milliseconds on a modest instance. You trade some recall for speed by tuning the index, and you manage index memory yourself. Past that scale a purpose-built store will be faster.
Can I run everything on the edge runtime?: No, and you should not try. The edge is the right place to stream chat completions because it has no cold start and low time-to-first-byte. It cannot run Node-only libraries, it has shorter timeouts, and it needs a connection pooler to talk to Postgres. Keep Stripe webhooks, background jobs, and heavy processing on the Node runtime. The boilerplate splits routes this way by default.
Is it a one-time payment?: Yes. The boilerplate is a one-time $89.99 with lifetime updates and a secure Stripe checkout. There is no subscription and no per-seat fee for the code.

Start with the boilerplate

If the tradeoffs above match how you want to build, the full AI SaaS boilerplate is a one-time $89.99 with lifetime updates. Prefer to plan the build first? Read how to build an AI SaaS in 2026.

Get the full stack boilerplate ($89.99)