pREST v2: Brazilian-Led API Tooling Gains Native MCP Support

Host: Hey everyone, welcome back to Allur! I’m your host, Alex Chan, and I am so glad you’re joining us today. If you’ve been following the show for a while, you know we love talking about how to make the developer experience smoother—especially when it comes to the intersection of backend data and the "wild west" of AI integration. Host: Joining me today is Thiago Silva. Thiago is a Senior Backend Engineer and a long-time contributor to the open-source scene in Brazil. He’s been a vocal advocate for pREST and has been following its evolution from a simple middleware tool to this sophisticated AI enabler it’s becoming today. Thiago, welcome to Allur! It’s so great to have you here. Guest: Hey Alex! Thanks so much for having me. It’s a real pleasure to be here and talk about pREST. We’re all very excited about what’s happening with the project right now back home in Brazil and globally. Host: So, Thiago, before we dive into the technical weeds of the new release, let's start at the beginning. For those who haven't heard of it, what exactly is pREST, and why has it built such a strong following, particularly in the Brazilian dev community? Guest: Right, so, at its core, pREST is an "instant" API tool. You point it at your PostgreSQL database, and it automatically generates a RESTful API for you. It’s written in Go, so it’s super fast. The idea is to stop writing the same boilerplate CRUD code over and over again. And you mentioned the Brazilian roots—that’s actually a huge part of the identity. Projects like TabNews, which is a big tech hub in Brazil, have really championed it. It’s become a bit of a "homegrown hero" project. We saw a need for something that was lightweight but production-ready, and pREST just clicked. Host: I love that. It’s always inspiring to see a local community drive a tool that ends up having global utility. Now, let’s talk about the big news: Version 2.1.0. The headline feature is native MCP support. For those of us who might still be catching up on the AI acronyms, what is the Model Context Protocol, and why did pREST need it? Guest: Oh, man, MCP is the "missing link" right now. So, think about it: when you give data to an AI model—like a GPT or a Claude—usually you're just throwing raw JSON at it. But raw data doesn't tell the whole story. The AI might see a number, but it doesn't know if that's a price, a stock count, or a timestamp without a lot of prompting. MCP—the Model Context Protocol—is a standardized way to package that data with *context*. It includes metadata, relationships, and operational rules. Host: Interesting! So it’s not just "here is the data," it’s "here is the data and here is the instruction manual on how to use it"? Guest: Exactly! And by pREST adding *native* support, it means you don’t have to write a middle layer to translate your database rows into MCP. pREST does it for you. You hit an endpoint, and the AI agent gets a response that is basically "pre-chewed" and ready for its reasoning engine. It reduces the chance of the AI hallucinating or misinterpreting a database field. Host: That sounds like a massive time-saver. I mean, um, I’ve spent way too many hours writing "wrapper" services just to format data for LLMs. But there’s another feature in this release that caught my eye: multi-database routing. How does that work in practice? Guest: Yeah, this one is huge for scaling. In the old version, one pREST instance talked to one database. But as systems grow, you often shard your data or move into microservices. With v2.1.0, you can have a single pREST instance acting as a gateway. So, you could send a request to `/users` and pREST routes it to your `user_db`, but a request to `/orders` goes to an entirely different physical database. Host: Oh, wow. So it’s essentially acting like a smart API gateway but specifically for your data layer? Guest: Precisely. You define these routing rules in the config, and it handles the connections. It makes the infrastructure look much simpler from the outside. Your frontend or your AI agent only sees one API, but behind the scenes, you could be talking to ten different PostgreSQL clusters. It’s actually quite elegant because it decouples the service from the physical storage location. Host: I can see how that would be a lifesaver for anyone dealing with legacy databases. You could essentially "unify" a fragmented data landscape without moving all the data into one place. Guest: Exactly. And when you combine that with MCP? That’s where the magic happens. Imagine an AI agent that needs to check inventory in one DB and customer loyalty points in another. It makes one call through pREST, gets back context-rich data from both sources, and can make an autonomous decision. Host: That's a perfect segue into the AI workflows. Can you walk me through a real-world scenario? Like, say I'm building a supply chain bot. How does this v2 update change my life? Guest: Okay, so let’s say your bot needs to decide whether to reorder "Product A." In the past, you’d have to write code to query the DB, fetch the product, fetch the supplier info, maybe fetch some JSONB data about shipping trends, format it all, and send it to the AI. With pREST v2, the bot just calls `GET /mcp/products/123`. pREST looks at the PostgreSQL schema, sees the relationships, pulls the JSONB data—PostgreSQL is amazing for that, by the way—and serves it as an MCP-compliant object. The bot gets the inventory level *plus* the context that "low stock" for this item means less than 50 units. It can then trigger the reorder instantly. No intermediate ETL, no stale data. It’s all live. Host: That "no stale data" part is key. Using live PostgreSQL data instead of a static vector database or a weekly export... that’s a big deal for accuracy. Guest: It really is. And since PostgreSQL has things like PostGIS for location or JSONB for semi-structured data, pREST can expose all of that "rich" data to the AI. It's not just strings and integers anymore. Host: It feels like Brazil is really carving out a niche here in the "AI-Ready Data" space. What’s the vibe like in the community right now? Are people actually switching over to this for their production AI apps? Guest: Oh, absolutely. The discussions on TabNews have been wild lately. Actually, there’s a lot of pride in seeing a Brazilian-led project solve a problem that global giants are also struggling with. We’re seeing developers move away from complex custom-built middleware and just dropping pREST in because it’s "set and forget." It’s democratizing this kind of high-level AI integration. You don’t need a team of twenty data engineers to build a context-aware AI agent anymore. Host: That is so empowering. Before we wrap up, Thiago, what’s next? If pREST is already doing MCP and multi-db routing, where does it go from here? Guest: The focus now is on even deeper integration with AI orchestration frameworks. Think about things like LangChain or AutoGPT. We want pREST to be the "default" data source for those tools. And of course, the community is always working on performance. We want to make sure that even with complex routing and MCP metadata, the latency stays near zero. Host: Near-zero latency and context-rich data... that’s the dream! Thiago, thank you so much for breaking this down. I’ve definitely had a few "aha moments" today regarding how we handle data for AI. Guest: My pleasure, Alex! Thanks for having me and for highlighting what we’re building in Brazil. Host: What a fascinating look at the evolution of pREST. It’s a great reminder that some of the most impactful tools in tech are born out of a specific community's need to simplify and streamline. If you’re working with PostgreSQL and you’re looking to bridge the gap to AI agents without losing your mind in the process, pREST v2.1.0 is definitely something you should check out. You can find their work on GitHub—just search for "pREST"—and check out the discussions on TabNews if you want to see the community in action.