Exploring conversational database building

Another in the series of blogs where I try to demystify things I've been building and working on, and why they might matter beyond the technical details, but also diving into some of the TechFreedom lens. This time: connecting AI to databases, hitting walls with Airtable's API, and why open source makes more things possible.

I've been spending a lot of time working within Airtable over the last week or so for a project. I've used Airtable for a good number of years and think it's genuinely good software, intuitive, user-friendly, powerful for a lot of use cases. But like everything, it's not without its limitations, like when you need to create large bases with complex data structures. Doing it all through the UI becomes a bit of an annoyingly slow process. Clicking through field after field, table after table, configuring options one at a time. Airtable lets you create bases from csv and their AI assistant is actually pretty good, but when things get beyond simple these methods don't really work.

As this was what I was actually doing, I decided to build something to solve the immediate problem. A JSON uploader that let me define a data structure in JSON and push it into Airtable via their API. Define your tables, fields, and relationships in a structured format, run the script, and the base is built. I'm honestly surprised Airtable haven't done this themselves.

So far so good. But I wondered if I could go further obviously! The uploader was good, but a little inflexible. It worked perfectly for the exact JSON structure I'd defined, but it was slightly limited to specific structures and so to make tweaks, change something, or handle a slightly different schema, I was back to either modifying the uploader or doing things manually. I could have built an adapter into the uploader (and still might) which allows this flexibility, but my mind went somewhere else first...

Enter MCP servers

This is where I started thinking about a different approach. Rather than building specific tools for specific tasks, what if I could create a persistent connection between an AI system and Airtable, one that could understand the base, work with it conversationally, and do whatever I needed, when I needed it?

If you're not familiar with MCP (Model Context Protocol), here's the short version: it's a standard way for AI tools to connect to external services. Think of it as a translator that sits between something like Claude or another AI assistant and a service like Airtable. The AI talks in natural language, the MCP server translates that into API calls, and suddenly you can say "create a table called Organisations with fields for name, postcode, and a linked record to Services" and it just... does it.

Airtable already has an official MCP server. It lets you do certain things, search and analyse data, create records, update existing ones, but it didn't do ALL the things I wanted like actually build bases. So I took that as a starting point, extended it, and gave myself more options. I could now connect Claude or Mistral, or Gemini or a local model directly into Airtable and work with it properly, not just reading what was in a base, but creating tables, creating fields, adding records, restructuring things. Conversational database management, essentially.

And it was incredibly useful. For the kind of work I do building data structures for organisations, setting up CRM-like systems, creating directories, being able to describe what I need, provide JSON structures, markdown docs of definitions etc and have it built is a significant step up from clicking through forms.

Hitting the walls

But then I started running into limitations. Not with the MCP server I'd built, but with what Airtable's API actually allows you to do.

You can't create views via the API. You can't create interfaces. You can't create certain field types, formula fields being the big one, which are actually really fundamental to how most complex Airtable bases work. You can list and remove views, but you can't create them programmatically.

Now, these aren't technical limitations in the traditional sense. Airtable could expose these capabilities. They've chosen not to. And when you think about why, it makes a kind of commercial sense. Every capability you can't automate is a capability that keeps you in their UI. Every limitation in the API is a reason you need to keep logging in, keep your team on paid accounts, keep building within their ecosystem rather than around it.

This is a strategic decision, not a technical one.

Baserow: the open source alternative

This got me thinking about alternatives, specifically Baserow. It's an open source, EU built alternative to Airtable.

Baserow is API-first. That means every feature is designed to be an integration endpoint. When I extended the Baserow MCP server, I found I could do significantly more than with Airtable. The API is more complete because it's not designed to keep you inside a walled garden, it's designed to be useful. Creating views, managing fields including formulas, working with the full range of capabilities that the UI offers. The gap between what you can do in the interface and what you can do via the API is much, much smaller..

Now of course even saying all that, Baserow isn't perfect either. It doesn't have every feature Airtable has. The ecosystem is smaller, the polish isn't quite there in places. But the foundations are different in ways that potentially make it more useful for some organisations, it's all just about choosing what you value.

The TechFreedom lens

This experience maps really well onto the kind of thinking we do in TechFreedom, the programme Doug Belshaw and I are helping mission-driven organisations examine their technology dependencies. We look at technology choices through five lenses:

Jurisdiction. Where is your data? Who has legal authority over it? Airtable is US-based, data primarily in the US. Baserow is Dutch, data stored in Amsterdam.

Business continuity. What happens if the vendor disappears or changes their pricing? With Baserow, the MIT licence means the software continues regardless. Your data is in PostgreSQL, not a proprietary format.

Lock-in. How easy is it to leave? When your API won't let you recreate your views, formulas, or interfaces programmatically, migration is harder than it needs to be.

Surveillance and data access. Who else can see your data, and under what legal frameworks? US-hosted and EU-hosted data sit under different rules.

Cost exposure. Airtable's per-seat pricing scales quickly. Baserow starts free, paid from $10 per user per month. Self-hosting eliminates per-user costs entirely.

None of these lenses give you a simple answer. What they aim to do is give you a framework for thinking about what you're trading when you pick a tool.

When you're choosing tools, the question isn't just "what can this do today?" It should be "what will this let me do tomorrow?" Proprietary platforms set that ceiling based on their commercial interests. Open platforms set it based on what you're willing to build. For organisations watching their budgets and trying to stay resilient, I think that difference adds up.

If you're thinking about any of this stuff database choices, AI integrations, technology dependencies or if you want to explore what TechFreedom could look like for your organisation, get in touch, find me on LinkedIn, or sign up to the TechFreedom cohort!