Launching today
Powabase
Build AI apps with Postgres, RAG, and agents
714 followers
Build AI apps with Postgres, RAG, and agents
714 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.
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.
Very cool @hunter_powabase ! Upvoted :)
So the only thing I need to bring is API key for LLMs?
Powabase
@hunter_powabase @aiswarya_s Thanks for the upvote! Bring your API key is an option that many of our users prefer. We are also giving our users the option to use powabase's key out of box so they don't have to get their own - should be out in the next product update.
Powabase
@hunter_powabase @aiswarya_s Yes, for now — bring an LLM API key (OpenAI, Anthropic, Google, or any model via OpenRouter) and you're set. Embeddings, rerankers, OCR, web search, and scraping are all wired in with no extra accounts. We're actually rolling out an even simpler onboarding soon where new users can start with Powabase's LLM access out of the box (bring-your-own-key stays supported and gets you the best margin). What are you planning to build?
Powabase
@hunter_powabase @aiswarya_s hey, quick update, we just shipped an update: bringing your own LLM API key is now optional. New sign-ups get $20 in Powabase credits to start with, covering LLM access (Claude, GPT, Gemini, etc.) along with everything else. Bring-your-own-key stays supported and gives you the best margin at scale, but now you can start building with zero outside accounts.
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.
How much time took to do it?
Powabase
@mykola_s The idea came to us about a year ago. We started building by using Supabase's open source codebase as a baseline, then extended it with our own unique features and integrations.
Powabase is not a "static" solution. Given how quickly the AI landscape shifts, we need to be moving with it as well. So the work is never truly finished. Going from Supabase open source baseline to v1 of production-ready Powabase took about 6-7 months.
Shoutout to Claude Code. It's a great coding assistant that really helped us accelerate the development process.
I love working with @Powabase and @hunter_powabase for Ryden Solutions, the first & leading life science continuous quality and compliance assessment platform simulating FDA inspectors at all times while also becoming more efficient. Hunter's platform has simplified development and set us up for long term success as we scale.
Powabase
@hunter_powabase @adam_foresman Thank you so much! Ryden Solutions has been one of the most rewarding projects we've worked on — what your team is building is exactly the kind of regulated-industry use case that pushed us to take Powabase's primitives seriously. We have learned a ton from working with you. Excited to keep building together!
Powabase
@adam_foresman Thanks a lot Adam! Your positive feedback made my day!
Powabase is perfect for use cases like Ryden. It's ideal for anything document-heavy and privacy-sensitive.
Looking forward to our continued partnership!
Powabase
@1lastshot thanks for your support! Powabase essentially evolved out of GPT-trainer. We learned a lot of lessons when we tried using it as an AI agent platform for other apps we were building (e.g. AI-powered document processing) but ran into pain points with GPT-trianer's focus on chatbots. We're hoping that Powabase, "backend we wish we had", will help others build AI-native apps too, and we'd love to hear more about what apps you may be trying to build!
Powabase
@1lastshot Following up from @michael_t_chang , Powabase was inspired by the fact that many users of GPT-trainer requested direct API access to the backend. Instead of stripping out the backend from an end-user SaaS, we thought it was best to properly address the root demand and build a dedicated AI-native BaaS instead.
Thank you for your positive feedback and encouragement!!