database.build v2: Bring-your-own-LLM

We've been hard at work since launching

In case you missed it, database.build is an - a WASM build of Postgres that can run directly in the browser.

With database.build, simply describe what you would like to build and AI will help you scaffold your tables. You can also drag-and-drop CSVs to automatically generate tables based on their contents, then query them using regular SQL.

Bring your own LLM

Since day one, our goal has been to make database.build freely accessible to everyone. To achieve this while also mitigating abuse (and sky-high OpenAI bills), we required users to sign in with their GitHub accounts. We also introduced modest rate limits to throttle excessive AI usage and ensure fair access for everyone.

Though this setup has worked well for most users, power users have reported regularly hitting these rate limits. Others have expressed interest in experimenting with alternative models or even running database.build entirely locally. These are all valid use cases we're excited to support. That's why today, we're introducing a new option: connect your own Large Language Model (LLM) via any OpenAI-compatible provider.

When you bring your own LLM, you get:

• 
  No login required: Build AI-assisted databases without needing a GitHub account.


• 
  No rate limits: Your usage is only limited by your chosen provider.


• 
  More control: Ensure your chat messages go only to providers you trust.


• 
  Greater flexibility: Choose your model and customize prompts to suit your needs.

For organizations with strict AI policies or firewall restrictions, BYO-LLM makes it easy to route AI messages through company-approved API endpoints, like Azure's OpenAI Service.

OpenAI compatibility

If you've worked with large language models, you've probably noticed that OpenAI's API structure has become an unofficial standard. Many LLM providers now offer OpenAI-compatible APIs, making it easier to use alternative models with existing tools and libraries built around OpenAI's APIs.

This is great news for BYO-LLM, as it means connecting to other LLM providers beyond OpenAI (such as , since it also has an OpenAI-compatible API? The answer is yes! But with a few limitations, keep reading!

How to use it

At the left of database.build's header you'll find a new button labeled Bring your own LLM. Tap this button to open a sidebar where you can connect your own LLM provider.

Note that all settings and keys are stored locally and never leave your browser. Even the API requests themselves are or any other provider that you choose - and this will always be cross-origin since requests are coming from the browser. The good news is: that most LLM providers add CORS headers by default which means we can connect directly to their APIs from the browser with no extra work. Without this, our only option would be to route every request through a backend proxy (which is not subject to CORS restrictions).

Service workers

If you've ever dug into database.build's to simplify LLM streaming and client-side tool calls. Vercel has built a great DX around inference by providing convenient hooks like useChat() to manage AI chat messages in React.

The challenge with Vercel's AI SDK for BYO-LLM is that the SDK expects a client-server API structure. useChat() connects to a server-side /api/chat route that is responsible for sending these messages downstream to the appropriate provider. In normal situations, this is the best architecture to protect API keys and custom logic on the server side. In our case though where users dynamically provide their own API keys, our preference is to send downstream requests directly from the browser. If we wish to continue using our existing useChat() infrastructure, we need a way to intercept requests to /api/chat and handle them ourselves in-browser.

(service workers don't have access to local storage, so we opt for IndexedDB).

for a fully local AI experience? Technically, yes—but there are a few caveats:

1. 
   Local models aren't great at tool calling (yet). While the latest state-of-the-art models like Llama 3.1/3.2 and Qwen 2.5 Coder technically support tool calls, versions that can run on consumer-grade hardware (like quantized models or lower-parameter variants) don't perform as consistently as their larger counterparts. These smaller models often fail to make tool calls when needed, call nonexistent tools, or pass invalid arguments.


2. 
   Tool streaming challenges. database.build relies on both tool calls and streaming to function. Ollama recently ), making it possible to use with database.build as long as the model can handle tool calls correctly. However, while Ollama does provide a tool streaming API, the current behavior buffers the entire response until it's complete before sending it in a single delta message. This creates the impression of slower performance on the frontend, even though the backend processes normally. The Ollama team is
   
   
   

   
   
   
   Deployments
   

   
   
   

   One of the most requested features has been a way to easily deploy your databases to the cloud with a single click.

   
   
   

   As a quick reminder - all database.build databases run directly in your browser using PGlite. This client-side approach makes it easy to spin up virtually limitless databases for design and experimentation. But when it's time to use your database in production, the options have been somewhat cumbersome:

   
   
   
   
   
   • Manually copy-pasting the generated migrations and running them against a real database
   
   
   • Using Live Share with pg_dump and pg_restore to back up and restore your browser database to a production-ready database
   
   
   
   
   

   Now with deployments, you can deploy your database.build creations directly to a cloud database provider, starting with Supabase (and AWS coming soon).

   
   
   

   
   
   
   Deploy to Supabase
   

   
   
   

   After building your database schema, click the Deploy button in the app's header.

   
   
   

   The first time you deploy to Supabase, you will need to connect your database.build account with your Supabase account. If you don't already have a Supabase account, you'll be given the option to create a new one here. Supabase includes a Free plan, so if this is your first project there will be no cost to deploy. Follow the steps outlined in the dialog to connect your account with a Supabase org.

   
   
   

   Once your account is connected you will be presented with a preview of the org and project name that will be created. If you are happy with this, click Deploy. Be sure to keep your browser tab open to ensure a successful deployment.

   
   
   

   Finally, you will be presented with connection strings and a password to connect to your new database.

   
   
   

   
   
   
   Behind the scenes
   

   
   
   

   Getting deployments to work took quite a bit more engineering than it might seem at first glance. To copy your in-browser database to the cloud accurately, we needed a way to dump and restore.

   
   
   

   We decided to piggyback on top of our existing Live Share feature, which creates a reverse connection between your in-browser database and an external PostgreSQL client. With Live Share enabled, we connect a server-side pg_dump program directly to your in-browser database. The resulting dump is then piped into pg_restore, which transfers it to your new cloud database.

   
   
   

   released a WASM version of pg_dump that we're excited to integrate in the future. Generating the dump directly in the browser will likely be faster and more reliable with less moving parts.

   
   
   

   
   
   
   What about serverless PGlite?
   

   
   
   

   Back when we first launched database.build, we shared plans to explore a serverless PGlite deployment option. However as we moved forward, we encountered a number of small but significant challenges that added up over time. PGlite's memory usage in multi-tenant environments turned out to be higher than anticipated—a problem the ElectricSQL team is actively working to address. Given PGlite's single-connection limit, anything more than a few megabytes of RAM will not be practical in a serverless environment. Additionally, our initial reliance on s3fs for storage proved to be less reliable than expected, making it difficult to meet the requirements for a seamless serverless experience.

   
   
   

   While these challenges have pushed us to focus on alternative deployment options for now, we remain committed to revisiting serverless options as these issues are resolved and the ecosystem continues to evolve.

   
   
   

   
   
   
   Drag and drop SQL files
   

   
   
   

   You've always been able to drag and drop CSV files into the chat, but what about SQL files? In this new release, simply dropping a SQL file onto that chat will automatically load its contents into your browser DB.

   
   
   

   This can be useful if you have existing schema or migrations that were designed elsewhere that you wish to extend or ask questions about.

   
   
   

   
   
   
   Download PGlite databases via pg_dump
   

   
   
   

   You can now dump your in-browser database to a SQL file using a WASM version of pg_dump.

   
   
   

   Previously when you went to download your database, we were exporting PGlite's internal pgdata directory as a .tar.gz file. This format was a bit cumbersome to work with, and was only compatible with other PGlite instances. Now when you hit Download, you'll get a .sql file that you can import into any Postgres database.

   
   
   

   Kudos to the ElectricSQL team for continually breaking new ground with embeddable Postgres. WASM pg_dump is a huge step forward for the project, and we're excited to see what other tools they bring to the browser in the future.

   
   
   

   
   
   
   Redesign
   

   
   
   

   We're thrilled to announce a complete redesign of database.build, bringing a sleek new look and enhanced functionality.

   
   
   

   The update includes seamless support for both desktop and mobile platforms, ensuring a smooth and intuitive experience across all devices. Get ready to build your databases anytime, anywhere!

   
   
   
   
   

   
   
   
   Wrapping up
   

   
   
   

   Everything we've shipped today - BYO-LLM, Live Share, Deployments, drag-drop SQL, and mobile support - is built on an open-source foundation. We believe in transparency, community collaboration, and making tools like database.build accessible to everyone.

   
   
   

   If you're curious about how it all works under the hood or want to contribute, you can find the entire project on GitHub:
   
   

   
   
   
   
   
   
   
   Vollständiger Original-Bericht

   Ausführliche Details, Code-Beispiele & Hersteller-Stellungnahme auf dev.to.

   ↗ Original-Artikel auf dev.to lesen