Launched this week
Powabase
Build AI apps with Postgres, RAG, and agents
1.2K followers
Build AI apps with Postgres, RAG, and agents
1.2K followers
Powabase is a backend-as-a-service for AI-native applications, combining Postgres, RAG, agents, memory, workflows, and automation primitives in one platform. It helps agencies and in-house IT teams build new AI apps or add AI automation to existing products without stitching together fragmented infrastructure. Designed to work seamlessly with modern coding agents, Powabase helps teams ship faster while building more robust, token-efficient systems.
The Postgres-native approach is interesting most RAG tooling treats the database as an afterthought rather than the foundation. Curious how you're handling vector indexing at scale: are you using pgvector under the hood, or did you build something custom? Would also love to know if the agent layer supports tool-calling across multiple data sources or just within a single Powabase instance.
Powabase
@fberrez1 Yep, we are using pgvector under the hood. For multimodal content, we first convert the data into a text-based description using a VLM like Mistral OCR, then index the text. At retrieval time, the database searches the indexed text but pulls the original multimodal content (e.g., base 64 image) and feeds it as context to the LLM.
Agent layer does support tool-calling across multiple data sources. Out-of-the-box tools interface mostly with built-in capabilities of the BaaS itself (e.g., sandbox code execution, permissioned db read/write, web search via Exa, web crawl via Firecrawl, etc.). You can connect custom tools or MCP servers to any agent or orchestrations to supplement its set of tools.
Bababot
The biggest value honestly might not be speed, it’s reducing architectural chaos. AI stacks become fragmented unbeliveably fast 😅
Powabase
@aarav_pittman Indeed. A significant time sink during Powabase's design process was figuring out which available tools are best to include. There are so many out there and some optimize for performance while disregarding cost, some try to strike a good balance and aim at best value, and others make the pure open source free-to-use play.
Example: VLM-based text extraction include LightOnOCR-2, Mistral, or PaddleOCR. This is the default approach for our RAG ETL pipeline. But if you know the source is all native text, you can opt into faster and cheaper non-VLM parsers like OpenDataLoader, PyMuPDF (fitz), or pdfplumber.
We generally try to give developers a choice while setting default options to what we believe is the best value for most common use cases.
Powabase
@aarav_pittman Yes! I've been building apps using Powabase as a backend, and it simplifies the management of all the different tools/integrations needed for an AI app
Serand
Curious how opinionated Powabase is internally. Can teams swap components easily, or is the goal more of an integrated ecosystem experience?
Powabase
@maali_baali Great question! There's a trade off to abstraction level (convenience) vs. control. Powabase definitely tries to strike the best balance based on our own experience building across many use cases during our dev shop days. If your use case involves building AI-native apps with RAG or ReAct agent orchestrations, then you'll find Powabase quite easy to use out of the box.
If your application needs something custom, you don't have to use the complete abstractions offered through Powabase. Instead, you can take relevant "intermediaries" and build a custom layer on top of those to better fit your design specifications. For example, if you need to supplement retrieved RAG context with metadata stored elsewhere, you can invoke the "context_handler" object to get you the content that normally "would have been fed into the agent", then enrich it with custom logic before forwarding it to your agent.
If you share more about what you're trying to build, then we'd be happy to advise you on which features would be most relevant on Powabase!
Powabase
@maali_baali there's a lot of flexibility built into Powabase for processing data sources and indexing them in different ways. In our experience with building client apps, that's where you can get a lot of value from tuning for your use case, e.g. long vs. short documents, scanned vs. digital native PDFs, images vs text-heavy sources.
The bundle is useful, but the make-or-break detail is how inspectable the agent layer is. For AI apps, Postgres + RAG gets you started; prompt/version history, retrieval traces, tool-call logs, and permission boundaries are what make it survivable in production.
Do you expose those traces as first-class objects, or mostly as dashboard logs?
Powabase
@studentzuo Thanks for asking!
Traces are first-class objects. Everything is API-accessible and persisted in your project's Postgres (ai schema), so you can query, replay, or export it however you like.
You can find details on our documentations page here: https://docs.powabase.ai/concepts/platform-overview. But in general:
Retrieval traces — GET /api/sessions/{id}/runs/{run_id}/retrieved-context returns every chunk the agent saw for that turn with retrieval_score, reranker_score, fused score, source/KB IDs, indexing strategy, and an included_in_context flag. So you can separate what was retrieved vs. what survived reranking vs. what actually made it into context.
Tool-call logs — GET /api/agents/runs/{run_id} returns the full run object: input_messages, output_messages, tool_calls, steps, events, reasoning_steps, usage, plus parent_orchestration_run_id / parent_workflow_execution_id to stitch delegated and workflow-embedded runs back to a parent. Same data streams live as discrete SSE events during execution.
Permission boundaries — Two layers. At the tool level, DB tools take a config_override.schemas whitelist (system schemas rejected, WHERE required for writes), http_request has SSRF validation, and a PreToolUse approval hook can pause execution until you (human) call /approve. At the project level, each project is an isolated stack, and the API enforces Service Role (bypasses RLS) vs. Anon key (respects RLS). Cross-tenant reads return 404, not 403, to avoid existence leaks.
AISA AI Skills Test
the 'glue code between 6-8 tools' problem is real. spent way too many hours on that exact pattern before. curious how you handle the agent runtime side specifically — is there built-in support for tool calling and memory across conversation turns, or is that something you still wire up yourself?
Powabase
@ozandag Yup, the agent orchestration we implemented follows Claude Code's architecture. We have many built-in tools with detailed configurations and permissions. Some of them rely on third party service providers like Exa and Firecrawl, but your Powabase credits cover their usage. You can also attach your own custom tools via API or MCP.
All agent conversations are put in "sessions" so agents working in the same session can maintain memory. You have full visibility and control over database tables handling sessions and respective agent / orchestration runs. You can also see retrieved context and tool use / output if your agent uses RAG or tools.
In general, there is no need to wire up anything yourself.
If you have specific abstractions in mind that we don't currently support, please share them with me. We're always happy to build it in.
Premarket Bell
I like that you’re focusing on token efficiency as a platform concern, not just a model concern. Hidden orchestration costs are becoming a massive issue.
Powabase
@daniel_henry4 Glad you noticed!
Two ways we impact token efficiency:
Building every project from first principles and debugging glue code+infra setup via Codex, Claude Code, or OpenCode can be VERY wasteful in terms of tokens. You can save significantly by leveraging well-crafted abstractions during development. This is where Powabase shines!
Traditional RAG or agent orchestrations done via Supabase + LangChain does not incorporate intelligent "agentic" retrieval. To get the right answer on the first try, you generally have to compensate with larger reserved context. This is wasteful in terms of tokens. Powabase's native multi-agent orchestration uses a similar architecture as Claude Code. When set up correctly, your agents can be much smarter about where to look for the most relevant pieces of context instead of stuffing everything in one go based on cosine similarity. You can also control reasoning levels directly if you want fewer "hidden reasoning tokens" at inference time.
Powabase
@daniel_henry4 Adding to Hunter's point — the unglamorous lever here is observability. Most "hidden" orchestration cost is hidden because the existing stack doesn't show it. We surface token usage broken down by model, agent, and source (agent run / orchestration / workflow), plus per-run trace with reasoning steps, tool calls, and the RAG context that got retrieved for each step. Once you can see it, the optimization is usually obvious — you stop arguing about prompt length when the real waste was a poorly-targeted retrieval call.
Nas.com
Can one deploy isolated environments per customer/org?
Powabase
@nuseir_yassin1 Yes, our enterprise plans offer dedicated hosting on client's chosen AWS region or their own data centers.
We also plan to offer a self-hosted open source version after early access period ends, likely around end of June / July 2026.